Fix: per-uid flush and ust registry locking
authorMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Thu, 15 Jan 2015 22:24:26 +0000 (17:24 -0500)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Thu, 22 Jan 2015 02:37:12 +0000 (21:37 -0500)
commit08ddb31a5e8c3f69899f464d0b85605b4cdebbe5
tree668f824c384ebafc859c898199cb3a4fddf81e40
parent75b7424d0f60dc23ca0d33ba21eab19f7715509b
Fix: per-uid flush and ust registry locking

Commit c4b88406 "Fix: ust-app: per-PID app unregister vs tracing stop
races" introduces a regression for per-UID flush. It can be triggered by
the test_high_throughput_limits (root regression) test. For per-UID
tracing, we need to use the registry channel ID, not the per-application
channel ID, when asking the consumer daemon to flush.

When doing this fix, we notice that the locking rules of push_metadata()
are weird. A per-ust app session lock is protecting registry data, which
makes it impossible to call push_metadata from a ust session level (for
the entire session) in the case of per-UID tracing. Moreover, it's
unclear how holding a per-application lock can protect a registry shared
across applications in per-UID tracing. Therefore, we move all accesses
to the registry metadata_key and metadata_closed fields into the
registry lock critical section. We now only rely on RCU to ensure
existance of registry across push_metadata(), rather than relying on the
per-application session lock.

It also takes care of a documentation vs code mismatch: push_metadata()
documents that "The session lock MUST be acquired here before calling
this.", but in reality, it's the application session lock which is held
across those calls. Removing this requirement, and relying on RCU
instead, fixes this mismatch.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
src/bin/lttng-sessiond/ust-app.c
This page took 0.024832 seconds and 4 git commands to generate.