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: 
 <IA1PR10MB7240AE0551BCF41FB1A69FD198DF2@IA1PR10MB7240.namprd10.prod.outlook.com>
Date: Fri, 5 Jul 2024 19:51:24 +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: 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.