Philippe Gerum authored Jan 31, 2020 and Jan Kiszka committed Jan 31, 2020

Since the vfile export and unexport operations are asynchronous,
returning from xnregistry_remove() is no guarantee that the registered
object won't be further accessed, especially by the vfile export
handler.

Plug this race at least for all in-band callers removing objects while
running on root stage like RTIPC protocols by synchronizing with the
workqueue which handles deferred export/unexport requests, before
returning from xnregistry_remove().

This does not cover the issue of removing objects from the head
stage. Fortunately, all users of the vfile export/unexport mechanism
are unregistering objects from the root stage only (typically some
RTDM close() handler).

This issue was reported by KASAN.

Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>