mirror of
https://github.com/systemd/systemd.git
synced 2024-11-05 23:51:28 +03:00
bb38678e3c
There's still a slight race condition when using udevadm settle, if the udev daemon has a pending inotify event but hasn't yet generated the "change" uevent for it, the kernel and udev sequence numbers will match and settle will exit. Now udevadm settle will send a control message to udevd, which will respond by sending SIGUSR1 back to the waiting udevadm settle once it has completed the main loop iteration in which it received the control message. If there were no pending inotify events, this will simply wake up the udev daemon and allow settle to continue. If there are pending inotify events, they are handled first in the main loop so when settle is continued they will have been turned into uevents and the kernel sequence number will have been incremented. Since the inotify event is pending for udevd when the close() system call returns (it's queued as part of the kernel handling for that system call), and since the kernel sequence number is incremented by writing to the uevent file (as udevd does), this solves the race. When the settle continues, if there were pending inotify events that udevd had not read, they are now pending uevents which settle can wait for. Signed-off-by: Scott James Remnant <scott@ubuntu.com> |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| exported_symbols | ||
| libudev-ctrl.c | ||
| libudev-device-db-write.c | ||
| libudev-device.c | ||
| libudev-enumerate.c | ||
| libudev-list.c | ||
| libudev-monitor.c | ||
| libudev-private.h | ||
| libudev-queue.c | ||
| libudev-util.c | ||
| libudev.c | ||
| libudev.h | ||
| libudev.pc.in | ||
| Makefile.am | ||
| test-libudev.c | ||