Fix: notification thread: RCU-safe reclaim of hash table nodes
authorMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Wed, 12 Dec 2018 17:16:44 +0000 (12:16 -0500)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Tue, 18 Dec 2018 21:02:47 +0000 (16:02 -0500)
commitb8778dda1857d107e2ef4736db5f530dda232b71
treeb99a193c124924d90323742c36f503acd42120ac
parentbde875091bf02f3ee9ad7b85fdbef76bbb59c317
Fix: notification thread: RCU-safe reclaim of hash table nodes

Nodes that are put in a rculfhash hash table created with the
"auto resize" flag need to beware that a worker thread can access the
hash table nodes as a RCU reader concurrently, and that this worker
thread can modify the hash table content, effectively adding and
removing "bucket" nodes, and changing the size of the hash table
index.

Therefore, even though only a single thread reads and updates the hash
table, a grace period is needed before reclaiming the memory holding
the rculfhash nodes.

Moreover, handle_notification_thread_command_add_channel() misses a
RCU read-side lock around iteration on the triggers hash table. Failure
to hold this read-side lock could cause segmentation faults when
accessing hash table objects if a hash table resize is done by the
worker thread in parallel with iteration over the hash table.

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