summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDaniel Drake <drake@endlessm.com>2015-04-06 16:03:43 -0600
committerAnthony G. Basile <blueness@gentoo.org>2015-04-12 13:18:48 -0400
commitcdbef8fd5a933de71c57cb1b4e337f1616f4a034 (patch)
tree9464fa3a79128c5c44a683af0c4ce5cb18dd24f1
parent1cd8de00b544c4f2ad97156c6c523209934bda9a (diff)
udevd: fix synchronization with settle when handling inotify events
udev uses inotify to implement a scheme where when the user closes a writable device node, a change uevent is forcefully generated. In the case of block devices, it actually requests a partition rescan. This currently can't be synchronized with "udevadm settle", i.e. this is not reliable in a script: sfdisk --change-id /dev/sda 1 81 udevadm settle mount /dev/sda1 /foo The settle call doesn't synchronize there, so at the same time we try to mount the device, udevd is busy removing the partition device nodes and readding them again. The mount call often happens in that moment where the partition node has been removed but not readded yet. This exact issue was fixed long ago: http://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=bb38678e3ccc02bcd970ccde3d8166a40edf92d3 but that fix is no longer valid now that sequence numbers are no longer used. Fix this by forcing another mainloop iteration after handling inotify events before unblocking settle. If the inotify event caused us to generate a "change" event, we'll pick that up in the following loop iteration, before we reach the end of the loop where we respond to settle's control message, unblocking it. Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
-rw-r--r--src/udev/udevd.c15
1 files changed, 14 insertions, 1 deletions
diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index 116494d373..4a9944d494 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -1453,9 +1453,22 @@ int main(int argc, char *argv[]) {
continue;
/* device node watch */
- if (is_inotify)
+ if (is_inotify) {
handle_inotify(udev);
+ /*
+ * settle might be waiting on us to determine the queue
+ * state. If we just handled an inotify event, we might have
+ * generated a "change" event, but we won't have queued up
+ * the resultant uevent yet.
+ *
+ * Before we go ahead and potentially tell settle that the
+ * queue is empty, lets loop one more time to update the
+ * queue state again before deciding.
+ */
+ continue;
+ }
+
/* tell settle that we are busy or idle, this needs to be before the
* PING handling
*/