ah, i haven't reproduced that one.
this patch fixes an issue that was easily reproduced with:
while true; do losetup -sf /etc/passwd & losetup -sf /etc/passwd ; done
which fails about half the iterations for me without this patch, and zero with.
On Mon, Aug 5, 2019 at 5:40 PM Ryan Prichard <rprich...@google.com> wrote:
>
> 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
