Re: [PATCH 4.21 V3] blk-mq: not embed .mq_kobj and ctx->kobj into queue instance

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

 



On 11/20/18 9:45 AM, Guenter Roeck wrote:
> On Tue, Nov 20, 2018 at 08:51:50AM +0100, Greg Kroah-Hartman wrote:
>> On Tue, Nov 20, 2018 at 09:44:35AM +0800, Ming Lei wrote:
>>> Even though .mq_kobj, ctx->kobj and q->kobj share same lifetime
>>> from block layer's view, actually they don't because userspace may
>>> grab one kobject anytime via sysfs.
>>>
>>> This patch fixes the issue by the following approach:
>>>
>>> 1) introduce 'struct blk_mq_ctxs' for holding .mq_kobj and managing
>>> all ctxs
>>>
>>> 2) free all allocated ctxs and the 'blk_mq_ctxs' instance in release
>>> handler of .mq_kobj
>>>
>>> 3) grab one ref of .mq_kobj before initializing each ctx->kobj, so that
>>> .mq_kobj is always released after all ctxs are freed.
>>>
>>> This patch fixes kernel panic issue during booting when DEBUG_KOBJECT_RELEASE
>>> is enabled.
>>>
>>> Reported-by: Guenter Roeck <linux@xxxxxxxxxxxx>
>>> Cc: "jianchao.wang" <jianchao.w.wang@xxxxxxxxxx>
>>> Cc: Guenter Roeck <linux@xxxxxxxxxxxx>
>>> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
>>> Cc: stable@xxxxxxxxxxxxxxx
>>> Signed-off-by: Ming Lei <ming.lei@xxxxxxxxxx>
>>> ---
>>> V3:
>>> 	- keep to allocate q->queue_ctx via percpu allocator, so one extra
>>> 	  pointer reference can be saved for getting ctx
>>> V2:
>>> 	- allocate 'blk_mq_ctx' inside blk_mq_init_allocated_queue()
>>> 	- allocate q->mq_kobj directly 
>>
>> Not tested, but seems sane from a kobject point-of-view:
>>
>> Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> 
> Tested-by: Guenter Roeck <linux@xxxxxxxxxxxx>
> 
> with v4.14.y and v4.19.y.
> 
> The patch is marked for v4.21. I would kindly suggest to not wait for v4.21
> but apply it to v4.20. This would let us enable DEBUG_KOBJECT_RELEASE
> with syzbot on upstream and stable kernels.

I'd very much like to put this into 4.21, and not 4.20, as that's much
less risky. This isn't a new regression anyway, so there's no rush to
put it into 4.20 as far as I'm concerned.

-- 
Jens Axboe




[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