[Toybox] [PATCH] losetup: fix the race.
Ryan Prichard
rprichard at google.com
Tue Aug 6 15:08:40 PDT 2019
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20190806/282fa7ce/attachment-0001.htm>
More information about the Toybox
mailing list