udevd: close race in udev settle

The udev-settle guarantees that udevd is no longer processing any of the
events casued by udev-trigger. The way this works is that it sends a
synchronous PING to udevd after udev-trigger has ran, and when that returns
it knows that udevd has started processing the events from udev-trigger.
udev-settle will then wait for the event queue to empty before returning.

However, there was a race here, as we would only update the /run state at
the beginning of the event loop, before reading out new events and before
processing the ping.

That means that if the first uevent arrived in the same event-loop iteration
as the PING, we would return the ping before updating the queue state in /run
(which would happen on the next iteration).

The race window here is tiny (as the /run state would probably get updated
before udev-settle got a chance to read /run), but still a possibility.

Fix the problem by updating the /run state as the last step before returning
the PING.

We must still update it at the beginning of the loop as well, otherwise we
risk being stuck in poll() with a stale state in /run.

Reported-by: Daniel Drake <drake@endlessm.com>

0 files changed, 0 insertions, 0 deletions