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

Denys Vlasenko vda.linux at googlemail.com
Wed Dec 9 20:16:15 UTC 2020


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


More information about the busybox mailing list