-
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>
997b8e18