On Wed, Aug 7, 2019 at 8:59 AM enh via Toybox <[email protected]> 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
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
