From: Jérémie Galarneau Date: Wed, 14 Jun 2023 23:03:12 +0000 (-0400) Subject: Fix: sessiond: crash enabling event rules that differ only by loglevel type X-Git-Url: https://git.liburcu.org/?a=commitdiff_plain;h=dcd24bbf7dbc74e3584d1d0d52715e749023c452;hp=dcd24bbf7dbc74e3584d1d0d52715e749023c452;p=lttng-tools.git 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 Signed-off-by: Jérémie Galarneau Change-Id: I869a0fb7a6554da7d84bc71df6ee91a7e46937cc ---