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>
Mon, 14 Jan 2019 22:56:28 +0000 (17:56 -0500)
commit83b934ad2222dc44bb58fee7157e63b29c300a13
treebd64687020fa0f29934e2171915f522b8f494f3d
parentc2e8c3663b99ba900f4733696c70e7a5e32ae1a7
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.024938 seconds and 4 git commands to generate.