Running xnregistry_enter() then xnregistry_remove() in quick
succession for the same object might cause the latter to NULLify the
objaddr field while proc_callback() is busy calling the vfile export
handler for the object, which is going to use that same value,
certainly leading to a crash.

This bug is due to the asynchronous nature of the vfile
export/unexport process which is deferred to a regular workqueue on
the root stage when kicked from the head stage.

Fix this by adding a third logic state describing an aborted vfile
export procedure, due to handling an object removal request while the
workqueue is concurrently running for the same object. In addition,
since an exported object might be stale before it is considered for
export, do not anticipate on the next object to process in
proc_callback() as list_for_each_entry_safe() would do, but always
pick the list head under lock.

At this chance, clarify the naming of the magic vfile values
enumerating those states (i.e. XNOBJECT_EXPORT_xxx).
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>