RE: [PATCH V6 for-6.11/block] loop: Fix a race between loop detach and loop open

[Gulam Mohamed]

Hi Christoph,

> -----Original Message-----
> From: Gulam Mohamed
> Sent: Saturday, July 6, 2024 1:21 AM
> To: hch@xxxxxx
> Cc: linux-block@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> yukuai1@xxxxxxxxxxxxxxx; axboe@xxxxxxxxx
> Subject: RE: [PATCH V6 for-6.11/block] loop: Fix a race between loop detach
> and loop open
> 
> Hi Christoph,
> 
> > -----Original Message-----
> > From: hch@xxxxxx <hch@xxxxxx>
> > Sent: Tuesday, July 2, 2024 9:20 PM
> > To: Gulam Mohamed <gulam.mohamed@xxxxxxxxxx>
> > Cc: hch@xxxxxx; linux-block@xxxxxxxxxxxxxxx;
> > linux-kernel@xxxxxxxxxxxxxxx; yukuai1@xxxxxxxxxxxxxxx;
> axboe@xxxxxxxxx
> > Subject: Re: [PATCH V6 for-6.11/block] loop: Fix a race between loop
> > detach and loop open
> >
> > Hi Gulam,
> >
> > On Sun, Jun 30, 2024 at 10:11:14PM +0000, Gulam Mohamed wrote:
> > > With our latest version of the patch V6, the "kernel robot test"
> > > failed in the ioctl_loop06 test (LTP tests) as in below mail.
> > > the reason for the failure is, the deferring of the "detach" loop
> > > device to release function. The test opens the loop device, sends
> > > LOOP_SET_BLOCK_SIZE and LOOP_CONFIGURE commands and in
> between
> > that,
> > > it will also detach the loop device. At the end of the test, while
> > > cleanup, it will close the loop device. As we deferred the detach to
> > > last close, the detach will be at the end only but before that we
> > > are setting the lo_state to Lo_rundown. This setting of Lo_rundown
> > > we are doing in the beginning because, there was another LTP test
> > > case failed earlier due to the same reason.
> > >
> > > So, when the LOOP_CONFIGURE was sent, the loop device was still in
> > > Lo_rundown state (Lo_unbound will be set after detach in
> > > __loop_clr_fd()) due to which kernel returned the EBUSY error
> > > causing the test to fail.
> >
> > Before we'd end up in Lo_unbound toward the end of __loop_clr_fd if
> > there was a single opener.
> >
> > > I have noticed that a good number of test cases are having a
> > > behaviour that it will send different loop commands and in between
> > > the detach command also, with only a single open. And close happens at
> the end.
> > > Due to this, I think a couple  of test cases needs to be modified.
> > >
> > > Now, as per my understanding, we have two options here:
> > >
> > > 1. Continue with this kernel patch and modify few test cases to
> > > accommodate this new kernel behaviour
> >
> > That would be my preference.  Any code that is doing a clear_fd and
> > then tries to configure it again is prone to races vs other openers.
> > It also does not seem very useful outside of test code.
> > But if we end up breaking real code and not test cases we might have
> > to go and bring it back.
> 
> Requested the maintainers of the LTP test cases for the modification to
> accomodate the new kernel behavior.

The LTP maintainers agreed to modify the impacted the test cases to accommodate the new kernel behavior. They are asking the kernel version/commit in which this new behavior is included.
Can you please help in integrating the path into the mainline?

Regards,
Gulam Mohamed.