[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <eb6e149f-7c2b-1e42-3479-5d514f80a818@fb.com>
Date: Fri, 29 Jul 2016 08:13:18 -0600
From: Jens Axboe <axboe@...com>
To: Vegard Nossum <vegard.nossum@...cle.com>,
Markus Pargmann <mpa@...gutronix.de>
CC: Quentin Casasnovas <quentin.casasnovas@...cle.com>,
<linux-block@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Paul Clements <paul.clements@...eleye.com>,
Pavel Machek <pavel@...e.cz>, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] nbd: fix race in ioctl
On 07/29/2016 04:55 AM, Vegard Nossum wrote:
> On 05/30/2016 02:58 PM, Markus Pargmann wrote:
>> Hi,
>>
>> On Friday 27 May 2016 12:59:35 Vegard Nossum wrote:
>>> Quentin ran into this bug:
>>>
>>> WARNING: CPU: 64 PID: 10085 at fs/sysfs/dir.c:31
>>> sysfs_warn_dup+0x65/0x80
>
> [...]
>
>>> It seems fairly obvious that device_create_file() is not being protected
>>> from being run concurrently on the same nbd.
>>>
>>> Quentin found the following relevant commits:
>>>
>>> 1a2ad21 nbd: add locking to nbd_ioctl
>>> 90b8f28 [PATCH] end of methods switch: remove the old ones
>>> d4430d6 [PATCH] beginning of methods conversion
>>> 08f8585 [PATCH] move block_device_operations to blkdev.h
>>>
>>> It would seem that the race was introduced in the process of moving nbd
>>> from BKL to unlocked ioctls.
>>>
>>> By setting nbd->task_recv while the mutex is held, we can prevent other
>>> processes from running concurrently (since nbd->task_recv is also
>>> checked
>>> while the mutex is held).
>>>
>>> Reported-and-tested-by: Quentin Casasnovas
>>> <quentin.casasnovas@...cle.com>
>>> Cc: Markus Pargmann <mpa@...gutronix.de>
>>> Cc: Paul Clements <paul.clements@...eleye.com>
>>> Cc: Pavel Machek <pavel@...e.cz>
>>> Cc: Jens Axboe <axboe@...com>
>>> Cc: Al Viro <viro@...iv.linux.org.uk>
>>> Signed-off-by: Vegard Nossum <vegard.nossum@...cle.com>
>>
>> Thanks, applied.
>>
>> Best Regards,
>>
>> Markus
>
> Hi,
>
> I didn't see this patch in the batch that went into 4.8, so I'm just
> following up to make sure it doesn't get lost.
>
> Moreover, it should also probably go into stable.
I have applied it for 4.8.
--
Jens Axboe
Powered by blists - more mailing lists