<div dir="ltr">I think this patch fixes a race I noticed, but in practice I was hitting a different race. After <span style="font-size:13px;color:rgb(0,0,0)">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:</span><div><font color="#000000"><br></font></div><div><span style="color:rgb(0,0,0);font-size:13px">strace on failure:</span><br style="color:rgb(0,0,0);font-size:13px"><br><span style="color:rgb(0,0,0);font-size:13px"> ...</span><br style="color:rgb(0,0,0);font-size:13px"><span style="color:rgb(0,0,0);font-size:13px"> openat(AT_FDCWD, "BACKING", O_RDWR|O_CLOEXEC) = 3</span><br style="color:rgb(0,0,0);font-size:13px"><span style="color:rgb(0,0,0);font-size:13px"> openat(AT_FDCWD, "/dev/loop-control", O_RDWR) = 4</span><br style="color:rgb(0,0,0);font-size:13px"><span style="color:rgb(0,0,0);font-size:13px"> ioctl(4, LOOP_CTL_GET_FREE) = 105</span><br style="color:rgb(0,0,0);font-size:13px"><span style="color:rgb(0,0,0);font-size:13px"> faccessat(AT_FDCWD, "/dev/loop105", F_OK) = -1 ENOENT (No such file or directory)</span><br style="color:rgb(0,0,0);font-size:13px"><span style="color:rgb(0,0,0);font-size:13px"> close(4) = 0</span><br style="color:rgb(0,0,0);font-size:13px"><span style="color:rgb(0,0,0);font-size:13px"> openat(AT_FDCWD, "/dev/block/loop105", O_RDWR) = -1 ENOENT (No such file or directory)</span><br style="color:rgb(0,0,0);font-size:13px"><span style="color:rgb(0,0,0);font-size:13px"> write(2, "losetup: ", 9losetup: ) = 9</span><br style="color:rgb(0,0,0);font-size:13px"><span style="color:rgb(0,0,0);font-size:13px"> write(2, "/dev/block/loop105", 18/dev/block/loop105) = 18</span><br style="color:rgb(0,0,0);font-size:13px"><span style="color:rgb(0,0,0);font-size:13px"> write(2, ": No such file or directory", 27: No such file or directory) = 27</span><br style="color:rgb(0,0,0);font-size:13px"><span style="color:rgb(0,0,0);font-size:13px"> write(2, "\n", 1</span><br style="color:rgb(0,0,0);font-size:13px"><span style="color:rgb(0,0,0);font-size:13px"> ...</span><font color="#000000"><br></font></div><div><font color="#000000"><br></font></div><div><font color="#000000">(At the time, losetup tried to open /dev/loopXXX before trying the Android /dev/block/loop/XXX.)</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">Maybe losetup can (busy) loop when open fails on ENOENT?</font></div><div><div><div><div><br></div><div>-Ryan</div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 5, 2019 at 4:35 PM enh via Toybox <<a href="mailto:toybox@lists.landley.net">toybox@lists.landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There's a race between LOOP_CTL_GET_FREE and LOOP_SET_FD. Work around it<br>
by just retrying if we get EBUSY on the LOOP_SET_FD call. This is what<br>
similar code in ChromeOS already does.<br>
<br>
Bug: <a href="http://b/135716654" rel="noreferrer" target="_blank">http://b/135716654</a><br>
---<br>
toys/other/losetup.c | 13 +++++++++----<br>
1 file changed, 9 insertions(+), 4 deletions(-)<br>
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div>