[PATCH 1/1] loop device: report mount failure in case of set_loop failure

[Denys Vlasenko]

On Wed, Dec 9, 2020 at 9:21 PM Thomas De Schampheleire
<patrickdepinguin at gmail.com> wrote:
> El mié, 9 dic 2020 a las 21:16, Denys Vlasenko
> (<vda.linux at googlemail.com>) escribió:
> > On Wed, Dec 9, 2020 at 9:08 PM Thomas De Schampheleire
> > <patrickdepinguin at gmail.com> wrote:
> > > > On Wed, Dec 9, 2020 at 10:19 AM Thomas De Schampheleire
> > > > <patrickdepinguin at gmail.com> wrote:
> > > > > From: Philippe Belet <philippe.belet at nokia.com>
> > > > >
> > > > > 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.