From: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Date: Tue, 11 Feb 2020 04:06:19 +0000 (-0500)
Subject: sessiond: notification: synchronize notification client (and list)
X-Git-Tag: v2.13.0-rc1~502
X-Git-Url: https://git.lttng.org/?p=lttng-tools.git;a=commitdiff_plain;h=505b2d90aa87592186ecc2a119cf67fb3f90d168;hp=505b2d90aa87592186ecc2a119cf67fb3f90d168

sessiond: notification: synchronize notification client (and list)

Introduce reference counting to notification_client_list and add
locks to both notification_client and notification_client list.

Of important note, this is in preparation for the introduction of
an action executor thread. The aim of this change is not to make
any part of the notitication sub-system thread-safe in any "general"
sense.

The reference counting and locks are introduced to protect a very
specific usage scenario.

The main thread of the notification subsystem and the action executor
will interact through triggers, evaluations, and client lists.

If the action executor needs to send a notification to a list of
client during the execution of an action group, it obtains the client
list and acquires a reference to it. It then locks the list to iterate
on it, allowing it to send the notification(s) to all subscribed
clients.

Holding the list lock prevents the main thread from disconnecting and
subsequently destroying a client. Holding a reference to the list also
prevents the list from being reclaimed due to a concurent 'unregister
trigger' operation.

No provision for other access scenarios are taken into account.

Squashed fix, otherwise the tests would hang.
	Fix: don't hold client lock while handling subscription changes

	Holding the client's lock while handling subscription changes causes a
	lock inversion between the client list lock and the client lock.

	This happens when a client subscribes to a condition that evaluates to
	'true' at the time of the subscription. When this happens, a
	notification is sent right away and that communication will attempt to
	acquire the client lock.

	Holding the client lock for such a long period is not needed anyhow
	and we can simply protect the communication state when it is actually
	modified/used.

	Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
	Change-Id: I7f38f81fa8bc32e5384538acdffab0824862cff2

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I88a9f66d31e3127b2bcc3f04016c364e0b3fe9ce
---