Messages in this thread | | | Subject | Re: [PATCH -next v2] block: fix blktrace debugfs entries leak | From | Yu Kuai <> | Date | Tue, 6 Jun 2023 11:58:09 +0800 |
| |
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
| |