[Toybox] [PATCH] losetup: fix the race.
enh
enh at google.com
Mon Aug 5 18:43:12 PDT 2019
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 <rprichard at 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 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
More information about the Toybox
mailing list