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

[enh]

and if the next stage in your personal "surely this can't be true?"
journey is the same as mine, the answer i got from our init maintainer
for the "why?" is that the kernel doesn't want to have an opinion on
permissions etc. (they pointed out that Android's setup actually
reduces the size of the window compared to the desktop.)

iirc, the adb maintainer has similar problems where when you first
connect an Android device to a Linux host, it shows up but with the
wrong permissions which then fix themselves if you wait+retry. which
for my money is even worse. (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.)

anyway, ping on the patch (which is actually for a completely
different EBUSY race condition)?

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

On Tue, Aug 6, 2019 at 3:08 PM Ryan Prichard <rprichard at google.com> wrote:
>
> On Tue, Aug 6, 2019 at 1:56 PM Rob Landley <rob at landley.net> wrote:
>>
>> On 8/5/19 7:40 PM, Ryan Prichard via Toybox 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,
>>
>> Why is the ioctl returning before the block device exists?
>
>
> I think the /dev/block/loopXXX file is created by a userspace daemon (probably ueventd in Android). The ioctl creates the kernel device, then sends an asynchronous uevent message to ueventd about the new device. ueventd and losetup then race each other to create the file and to open it.
>
> It looks like this code is responsible for creating device files on Android:
> https://android.googlesource.com/platform/system/core/+/924858cd18589de74e7f4347d27c77ca6a33716d/init/devices.cpp#270
>
> It looks like someone worked around a similar race involving losetup and udevd:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1045432#c10
> https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=663bf040611240d164f2464b4d892ecd2b02fa6f
>
> Summarizing the util-linux workaround:
>  - Make 16 attempts to open the device file.
>  - If the open fails with EACCES or ENOENT, sleep for 25ms, then try again.
>
> -Ryan
>