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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: 
 <IA1PR10MB7240AC320F4DBC43E73E758898DB2@IA1PR10MB7240.namprd10.prod.outlook.com>
Date: Tue, 9 Jul 2024 09:09:30 +0000
From: Gulam Mohamed <gulam.mohamed@...cle.com>
To: "hch@....de" <hch@....de>
CC: "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "yukuai1@...weicloud.com" <yukuai1@...weicloud.com>,
        "axboe@...nel.dk"
	<axboe@...nel.dk>
Subject: RE: [PATCH V6 for-6.11/block] loop: Fix a race between loop detach
 and loop open

Hi Christoph,

> -----Original Message-----
> From: Gulam Mohamed
> Sent: Saturday, July 6, 2024 1:21 AM
> To: hch@....de
> Cc: linux-block@...r.kernel.org; linux-kernel@...r.kernel.org;
> yukuai1@...weicloud.com; axboe@...nel.dk
> Subject: RE: [PATCH V6 for-6.11/block] loop: Fix a race between loop detach
> and loop open
> 
> Hi Christoph,
> 
> > -----Original Message-----
> > From: hch@....de <hch@....de>
> > Sent: Tuesday, July 2, 2024 9:20 PM
> > To: Gulam Mohamed <gulam.mohamed@...cle.com>
> > Cc: hch@....de; linux-block@...r.kernel.org;
> > linux-kernel@...r.kernel.org; yukuai1@...weicloud.com;
> axboe@...nel.dk
> > 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.