chiark / gitweb /
udevd: close race in udev settle
authorTom Gundersen <teg@jklm.no>
Mon, 9 Mar 2015 15:16:23 +0000 (16:16 +0100)
committerTom Gundersen <teg@jklm.no>
Mon, 9 Mar 2015 16:55:16 +0000 (17:55 +0100)
commitdb93e063bdffe0a8b95fcc522aeacddf62d1a9f9
treeb1dda4219b7d9d17a2ba70b4126105928214e69d
parentcf1755bac0426132c21fdca519a336ce7d920277
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>
src/udev/udevd.c