lkml.org 
[lkml]   [2023]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH -next v2] block: fix blktrace debugfs entries leak
From
Date
Hi, Christoph

在 2023/06/01 14:18, Christoph Hellwig 写道:
> On Thu, Jun 01, 2023 at 09:50:22AM +0800, Yu Kuai wrote:
>> Hi, Christoph
>>
>> 在 2023/05/31 20:44, Christoph Hellwig 写道:
>>> I like where this is going, but did you check that this doesn't
>>> introduce a potential crash with the current /dev/sg based blktrace?
>>
>> I just start to look at how /dev/sg is created and destroyed, however,
>> I'm confused here, do you mean that the added blk_trace_shutdown() here
>> might cause that /dev/sg blktrace to access freed momory or NULL
>> pointer?
>
> Yes. Given that __blk_trace_remove clears out q->blk_trace and
> frees the blk trace structure I'm worried about that.
>

sg ioctl call blktrace apis blk_trace_setup/startstop/remove(), and
these apis are all protected by 'q->debugfs_mutex', and they're safe
to call at anytime as long as request_queue is not released.

And I found that it's true sg can still enable blktrace through ioctl
after the related scsi device gendisk is released, I'm thinking about
following possible solution:

sg_device_destroy() is called at last, when all openers close and the
related device is deleted, so, I think we can get a queue reference
while initializing /dev/sg, and then remove blktrace and put queue
reference from sg_device_destroy().

Any suggestions?

Thanks,
Kuai

\
 
 \ /
  Last update: 2023-06-06 05:58    [W:2.213 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site