Message ID | 20230531092606.3037560-1-yukuai1@huaweicloud.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [-next,v2] block: fix blktrace debugfs entries leak | expand |
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?
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? Thanks, Kuai > > > . >
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.
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
diff --git a/block/genhd.c b/block/genhd.c index 1cb489b927d5..f5718367965c 100644 --- a/block/genhd.c +++ b/block/genhd.c @@ -25,8 +25,9 @@ #include <linux/pm_runtime.h> #include <linux/badblocks.h> #include <linux/part_stat.h> -#include "blk-throttle.h" +#include <linux/blktrace_api.h> +#include "blk-throttle.h" #include "blk.h" #include "blk-mq-sched.h" #include "blk-rq-qos.h" @@ -1171,6 +1172,10 @@ static void disk_release(struct device *dev) might_sleep(); WARN_ON_ONCE(disk_live(disk)); + mutex_lock(&disk->queue->debugfs_mutex); + blk_trace_shutdown(disk->queue); + mutex_unlock(&disk->queue->debugfs_mutex); + /* * To undo the all initialization from blk_mq_init_allocated_queue in * case of a probe failure where add_disk is never called we have to