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

Thomas De Schampheleire patrickdepinguin at gmail.com
Wed Dec 9 20:21:00 UTC 2020


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:
> > > >
> > > > stat64(/path/to/image, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
> > > > openat(AT_FDCWD, /path/to/image, O_RDWR|O_LARGEFILE) = 3
> > > > openat(AT_FDCWD, /dev/loop-control, O_RDWR|O_LARGEFILE|O_CLOEXEC) = 4
> > > > ioctl(4, LOOP_CTL_GET_FREE)             = 12
> > > > close(4)                                = 0
> > > > openat(AT_FDCWD, /dev/loop12, O_RDWR|O_LARGEFILE) = 4
> > > > ioctl(4, LOOP_GET_STATUS64, {lo_offset=0, lo_number=12, lo_flags=LO_FLAGS_AUTOCLEAR, lo_file_name=/path/to/image, ...}) = 0
> > > > close(4)                                = 0
> > > > close(3)                                = 0
> > > > write(2, "mount: can't setup loop device\n", 31mount: can't setup loop device
> > > > ) = 31
> > > > exit_group(0)                           = ?
> > > > +++ exited with 0 +++
> > > >
> > > > The ioctl LOOP_CTL_GET_FREE has resulted in the same result for
> > > > a competing mount process. The subsequent ioctl LOOP_GET_STATUS64
> > > > fails, having succeeded for the competing mount process. Next we
> > > > see a series of other system calls.
> > > >
> > > > The mount code checks the errno value of the last close()
> > > > syscall
> > >
> > > No it does not. errno is not cleared to zero on successful syscalls,
> > > it's left untouched.
> > >
> > > 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."

Thanks,
Thomas


More information about the busybox mailing list