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

[Ryan Prichard]

On Wed, Aug 7, 2019 at 8:59 AM enh via Toybox <toybox at lists.landley.net>
wrote:

> ... (but maybe not. there are pros and cons
> either way, and neither is ideal. and i'm guessing that Ryan's mention
> of EACCES means that he's seen that problem with losetup too.)
>

I've only seen the ENOENT error, on Android, and I'm guessing EACCES doesn't
happen on Android? ueventd only needs to set the uid after creating the new
/dev file, and the final uid for /dev/block/loopXXX appears to be root. I'm
not sure what the initial uid was -- also root, probably? Maybe EACCES
happens with other uevent/init daemons.

i'll see if i can reproduce this EACCES/ENOENT race condition when i
> have some spare time, now i understand the difference...
>

It's easy for me to reproduce on aosp/master, aosp_walleye. At startup, the
device has 8 unused loop devices, and once they're exhausted, losetup -sf
fails whenever ioctl creates a new device:

1|walleye:/ # losetup -sf /system/etc/ld.config.R.txt
/dev/block/loop10
walleye:/ # losetup -sf /system/etc/ld.config.R.txt
losetup: /dev/block/loop11: No such file or directory
1|walleye:/ # losetup -sf /system/etc/ld.config.R.txt
/dev/block/loop11
walleye:/ # losetup -sf /system/etc/ld.config.R.txt
losetup: /dev/block/loop12: No such file or directory
1|walleye:/ # losetup -sf /system/etc/ld.config.R.txt
/dev/block/loop12

FWIW, I think losetup -sf can also race with a process invoking
LOOP_CTL_REMOVE. i.e. ENOENT might indicate that the loop device had been
available, but some other process removed it before it could be opened.

-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20190807/231d240e/attachment-0001.htm>