On Mon, Jun 15, 2015 at 11:03:47AM +0200, Karel Zak wrote: > On Fri, Jun 12, 2015 at 09:44:03AM +0000, Felipe Franciosi wrote: > > Hi All, > > > > I'm seeing a race when using "losetup -f file". Some research > > pointed me to a 2007 path that introduced a "retry" mechanism if the > > module returned EBUSY. At some point before the project went into > > git.kernel.org this commit went away. > > I still see EBUSY sensitivity: > > https://github.com/karelzak/util-linux/blob/master/sys-utils/losetup.c#L684 > > the problem is probably loopcxt_setup_device() where we does not save > errno and does not set proper return value. > > I'll try to fix it. Thanks for you report! I'm not able to reproduce the problem, but I have pushed a small improvement to make the code less fragile: https://github.com/karelzak/util-linux/commit/2cde9865c27248bb1f7685b66a0a5830884f5869 My test: # for i in {0..99}; do dd if=/dev/zero of=$i.img count=1 bs=1MiB; done # for i in {0..99}; do strace -o $i.log losetup -f ./$i.img & done all devices created (100 device + header line): # losetup | wc -l 101 and many EBUSY detected: # grep BUSY *.log | wc -l 201 and from "losetup" output is obvious than many <n>.img files are associated with /dev/loop<n> where <n> is not the same number (due to EBUSY). Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
