[Toybox] [PATCH] losetup: fix the race.

[Ryan Prichard]

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 at 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 at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20190805/6ddb76ef/attachment-0001.htm>