I think this patch fixes a race I noticed, but in practice I was hitting a different race. After LOOP_CTL_GET_FREE had created a new loop device, losetup tried to open /dev/block/loopXXX before the device file existed, failing with ENOENT:
strace on failure: ... openat(AT_FDCWD, "BACKING", O_RDWR|O_CLOEXEC) = 3 openat(AT_FDCWD, "/dev/loop-control", O_RDWR) = 4 ioctl(4, LOOP_CTL_GET_FREE) = 105 faccessat(AT_FDCWD, "/dev/loop105", F_OK) = -1 ENOENT (No such file or directory) close(4) = 0 openat(AT_FDCWD, "/dev/block/loop105", O_RDWR) = -1 ENOENT (No such file or directory) write(2, "losetup: ", 9losetup: ) = 9 write(2, "/dev/block/loop105", 18/dev/block/loop105) = 18 write(2, ": No such file or directory", 27: No such file or directory) = 27 write(2, "\n", 1 ... (At the time, losetup tried to open /dev/loopXXX before trying the Android /dev/block/loop/XXX.) Maybe losetup can (busy) loop when open fails on ENOENT? -Ryan On Mon, Aug 5, 2019 at 4:35 PM enh via Toybox <toybox@lists.landley.net> wrote: > There's a race between LOOP_CTL_GET_FREE and LOOP_SET_FD. Work around it > by just retrying if we get EBUSY on the LOOP_SET_FD call. This is what > similar code in ChromeOS already does. > > Bug: http://b/135716654 > --- > toys/other/losetup.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > _______________________________________________ > Toybox mailing list > Toybox@lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net