Fix: sessiond: crash enabling event rules that differ only by loglevel type
authorJérémie Galarneau <jeremie.galarneau@efficios.com>
Mon, 17 Jul 2023 19:48:51 +0000 (15:48 -0400)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Mon, 17 Jul 2023 20:10:08 +0000 (16:10 -0400)
commit1083b49aa3c4914193157ca25978c01f4f8bca4c
treeef715e30e5085bb92eaa32663934ff59f1542f7a
parent4f4f479fa58421358aa94b9b3d21b6fed9f7067f
Fix: sessiond: crash enabling event rules that differ only by loglevel type

Issue observed
--------------

Summarizing bug #1373, an assertion fails when enabling two event-rules
that only differ by their log level selection type (all, range, or
single).

This issue can be reproduced by launching an instrumented
application (which remains active over the duration of this test) and
running:
  $ lttng create test_session
  $ lttng enable-channel --userspace test_channel
  $ lttng start test_session
  $ lttng enable-event --userspace --session test_session --channel test_channel 'l*' --loglevel-only=TRACE_DEBUG_LINE
  $ lttng enable-event --userspace --session test_session --channel test_channel 'l*' --loglevel=TRACE_DEBUG_LINE

Cause
-----

A number of sites conflate log level values and type. A clean-up had
been performed previously as of 2106efa08 and through follow-up commits.
However, some instances were apparently missed at the time.

As such, add_unique_ust_app_event mixed loglevel values and types when
initializing the key used for the unique insertion. The log level type,
for its part, is completely ignored.

Going back to the reproducer above, the first insertion succeeds as
expected. The second insertion fails since there is already an app event
rule with the `TRACE_DEBUG_LINE` log level type.

Moreover, the matching function only matches on the log level
type (which is really the value), which is also a bug.

The "matching" function is invoked on the key of the second event rule
and the first event rule since the hashing is only performed on the
event-rule's name pattern, resulting in a collision.

Solution
--------

Both the log level value and log level types are used to perform the
matching within the ust-app module. This implies extending the
ust_app_ht_key to store the log level value.

To simplify the matching logic (which attempted to handle 0 and -1
having the same meaning when the "ALL" log level type was used), the log
level value is normalized to '-1' throughout.

Fixes #1373
Reported-by: Bogdan Codres <bogdan.codres@windriver.com>
Change-Id: Id8090156646e4ef2011738623e0bfee1f400dced
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
src/bin/lttng-sessiond/ust-app.c
src/bin/lttng-sessiond/ust-app.h
src/common/event-rule/jul-logging.c
src/common/event-rule/log4j-logging.c
src/common/event-rule/python-logging.c
This page took 0.025994 seconds and 4 git commands to generate.