On Wed, Dec 9, 2020 at 9:21 PM Thomas De Schampheleire <[email protected]> wrote: > El mié, 9 dic 2020 a las 21:16, Denys Vlasenko > (<[email protected]>) escribió: > > On Wed, Dec 9, 2020 at 9:08 PM Thomas De Schampheleire > > <[email protected]> wrote: > > > > On Wed, Dec 9, 2020 at 10:19 AM Thomas De Schampheleire > > > > <[email protected]> wrote: > > > > > From: Philippe Belet <[email protected]> > > > > > > > > > > When mounting, in parallel, multiple loop devices (squashfs for the > > > > > submitter's case), the following behavior can be observed: > > > > > ... > > > > Does just this change: > > > > > > > > - return errno; > > > > + return loopfd; > > > > > > > > fix the problem? > > > > > > Yes, it seems so. At least with the given test program I get correct > > > results with this change alone. > > > > > > Will you adapt directly or should I send a new patch? > > > > Fixed in git already. Thank you > > Thanks. > > What are your thoughts about the fact that such parallel mounts fail? > If they would happen slightly apart in time, then they would succeed. > Quoted from the cover letter: > > "However, it feels to me as if the mount shouldn't fail: the scenario is that > /dev/loop-control gives a 'free' number which later turns out to be not free > anymore because another mount used it too. This is an error that mount itself > could resolve by retrying, possibly with a maximum amount of attempts."
Yes, it does not look like a good design. ioctl(LOOP_CTL_GET_FREE) should have been designed so that it takes a fd argument and perform LOOP_SET_FD on it if there is a free loop device... I rewrote the code so that it loops and tries ioctl(LOOP_CTL_GET_FREE) again on failure. please try it. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
