{"action":"closed","issue":{"url":"https://api.github.com/repos/systemd/systemd/issues/540","labels_url":"https://api.github.com/repos/systemd/systemd/issues/540/labels{/name}","comments_url":"https://api.github.com/repos/systemd/systemd/issues/540/comments","events_url":"https://api.github.com/repos/systemd/systemd/issues/540/events","html_url":"https://github.com/systemd/systemd/issues/540","id":94169628,"number":540,"title":"udev disk locking breaks syslinux/mtools","user":{"login":"joshtriplett","id":162737,"avatar_url":"https://avatars.githubusercontent.com/u/162737?v=3","gravatar_id":"","url":"https://api.github.com/users/joshtriplett","html_url":"https://github.com/joshtriplett","followers_url":"https://api.github.com/users/joshtriplett/followers","following_url":"https://api.github.com/users/joshtriplett/following{/other_user}","gists_url":"https://api.github.com/users/joshtriplett/gists{/gist_id}","starred_url":"https://api.github.com/users/joshtriplett/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/joshtriplett/subscriptions","organizations_url":"https://api.github.com/users/joshtriplett/orgs","repos_url":"https://api.github.com/users/joshtriplett/repos","events_url":"https://api.github.com/users/joshtriplett/events{/privacy}","received_events_url":"https://api.github.com/users/joshtriplett/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/systemd/systemd/labels/udev","name":"udev","color":"f7c6c7"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-07-09T22:47:39Z","updated_at":"2015-07-11T14:47:53Z","closed_at":"2015-07-11T14:47:53Z","body":"syslinux uses mtools to manipulate disk images when making them bootable. mtools attempts to acquire an exclusive lock on the device when opening it for writing, and fails if that lock acquisition fails.  At the same time, some part of setting up a loopback device (initially set up via losetup on the command line, then manipulated by syslinux) causes udev to open and lock that device, likely as part of the change in udev 214 to lock the disk device node.  This causes a race, and if mtools loses that race, it'll spuriously fail.  (This race was extremely timing-dependent and difficult to debug.)  Some instrumentation in the kernel flock error path produced this:\r\n\r\n```\r\n[   83.036178] Non-blocking flock failed: PID abs 4186 ns 2910 current->comm=mcopy holder PID abs 4187 ns 0 holder->comm=systemd-udevd\r\n```\r\n\r\n(The mcopy was run inside a PID namespace, and udev wasn't, hence the 0.)  This shows that mcopy's flock failed due to systemd-udevd's lock; systemd-udevd's system-wide PID being one more than mcopy suggests that the udev process that won the race for the lock started at almost the same time that syslinux started mcopy.\r\n\r\nNet result: a build script that invokes losetup and then syslinux (which invokes mtools) will spuriously fail due to a timing-dependent race.  This is currently causing spurious build failures in Chrome OS.\r\n\r\nI don't see any obvious way that such a build script can work around this.  I'd welcome suggestions for such a workaround to make the build script work with older udev versions, but for new versions, this seems to fall under the note in 214's NEWS saying \"if it turns out to cause major problems, we might turn it on only for specific devices, or might need to disable it entirely.\""}}