From: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Date: Wed, 13 Jun 2018 00:13:48 +0000 (-0400)
Subject: Fix: check for removal of session's shm_path in destroy()
X-Git-Tag: v2.11.0-rc1~161
X-Git-Url: https://git.liburcu.org/?a=commitdiff_plain;h=a503e1ef71bfe98526469205fc2956cc65954019;hp=a503e1ef71bfe98526469205fc2956cc65954019;p=lttng-tools.git

Fix: check for removal of session's shm_path in destroy()

When a session is created with an explicit shm_path,
the consumer daemon will create its shared memory files
at that location and will *not* unlink them. This is normal
as the intention of that feature is to make it possible
to retrieve the content of those files should a crash occur.

To ensure the content of those files can be used, the
sessiond daemon will replicate the content of the metadata
cache in a metadata file.

On clean-up, it is expected that the consumer daemon will
unlink the shared memory files and that the session daemon
will unlink the metadata file. Then, the session's directory
in the shm path can be removed.

Unfortunately, a flaw in the design of the sessiond's and
consumerd's tear down of channels makes it impossible to
determine when the sessiond _and_ the consumerd have both
destroyed their representation of a channel. For one, the
unlinking, close, and rmdir happen in deferred 'call_rcu'
callbacks in both daemons.

However, it is also impossible for the sessiond to know when
the consumer daemon is done destroying its channel(s) since
it occurs as a reaction to the closing of the channel's file
descriptor. There is no resulting communication initiated
from the consumerd to the sessiond to confirm that the
operation is completed (and was successful).

Until this is all fixed, the session daemon checks for the
removal of the session's shm path which makes it possible
to safely advertise a session as having been destroyed.

Prior to this fix, it was not possible to reliably save
a session making use of the --shm-path option, destroy it,
and load it again. This is because the creation of the
session would fail upon seeing the session's shm path
already in existence.

Note that none of the error paths in the check for the
directory's existence return an error. This is normal
as there isn't much that can be done. The session will
be destroyed properly, except that we can't offer the
guarantee that the same session can be re-created.

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