Re: Racy loop device reuse logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 19, 2022 at 09:52:47AM +0100, Jan Kara wrote:
> Ping? Any opinion?

 Sorry for the delay.

> On Thu 13-01-22 16:47:35, Jan Kara wrote:
> > Hello,
> > 
> > Tetsuo has been doing some changes to the loop device shutdown in the
> > kernel and that broke LTP that is doing essentially the following loop:
> > 
> > while :; do mount -o loop,ro isofs.iso isofs/; umount isofs/; done
> > 
> > And this loop is broken because of a subtle interaction with systemd-udev
> > that also opens the loop device. The race seems to be in mount(8) handling
> > itself and the altered kernel timing makes it happen. It look like:
> > 
> > bash					systemd-udev
> >   mount -o loop,ro isofs.iso isofs/
> >     /dev/loop0 is created and bound to isofs.iso, autoclear is set for
> >     loop0
> >   					opens /dev/loop0
> >   umount isofs/
> >   loop0 still lives because systemd-udev still has device open
> >   mount -o loop,ro isofs.iso isofs/
> >     gets to mnt_context_setup_loopdev()
> >       loopcxt_find_overlap()
> >       sees loop0 is still valid and with proper parameters
> >       reuse = true;
> > 					close /dev/loop0
> > 					  last fd closed => loop0 is
> > 					    cleaned up
> >       loopcxt_get_fd()
> >         opens loop0 but it is no longer the device we wanted!
> >     calls mount(2) which fails because we cannot read from the loop device
> > 
> > It seems to me that mnt_context_setup_loopdev() should actually recheck
> > that loop device parameters still match what we need after opening
> > /dev/loop0 (if LOOP_GET_STATUS ioctl succeeds on the fd, you are guaranteed
> > the loop device is in that state and will not be torn down under your
> > hands). What do you think?

Seems like elegant solution. Please, send a patch.

(It would be possible to be care about autoclear in
loopcxt_find_overlap(), but it sounds complicated and probably still
racy.

> > 
> > 								Honza
> > -- 
> > Jan Kara <jack@xxxxxxxx>
> > SUSE Labs, CR
> -- 
> Jan Kara <jack@xxxxxxxx>
> SUSE Labs, CR
> 

-- 
 Karel Zak  <kzak@xxxxxxxxxx>
 http://karelzak.blogspot.com




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux