public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH -next v2] block: fix blktrace debugfs entries leak
@ 2023-05-31  9:26 Yu Kuai
  2023-05-31  9:26 ` Yu Kuai
  2023-05-31 12:44 ` Christoph Hellwig
  0 siblings, 2 replies; 6+ messages in thread
From: Yu Kuai @ 2023-05-31  9:26 UTC (permalink / raw)
  To: hch, axboe
  Cc: linux-block, linux-kernel, yukuai3, yukuai1, yi.zhang, yangerkun

From: Yu Kuai <yukuai3@huawei.com>

Commit 99d055b4fd4b ("block: remove per-disk debugfs files in
blk_unregister_queue") moves blk_trace_shutdown() from
blk_release_queue() to blk_unregister_queue(), this is safe if blktrace
is created through sysfs, however, there is a regression in corner
case.

blktrace can still be enabled after del_gendisk() through ioctl if
the disk is opened before del_gendisk(), and if blktrace is not shutdown
through ioctl before closing the disk, debugfs entries will be leaked.

Fix this problem by shutdown blktrace in disk_release(), this is safe
because blk_trace_shutdown() is reentrant.

Noted that scsi sg can support blktrace without gendisk and still need
special handling to avoid this problem.

Fixes: 99d055b4fd4b ("block: remove per-disk debugfs files in blk_unregister_queue")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
---
 block/genhd.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

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
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [PATCH -next v2] block: fix blktrace debugfs entries leak
  2023-05-31  9:26 [PATCH -next v2] block: fix blktrace debugfs entries leak Yu Kuai
@ 2023-05-31  9:26 ` Yu Kuai
  2023-05-31 12:44 ` Christoph Hellwig
  1 sibling, 0 replies; 6+ messages in thread
From: Yu Kuai @ 2023-05-31  9:26 UTC (permalink / raw)
  To: hch, axboe
  Cc: linux-block, linux-kernel, yukuai3, yukuai1, yi.zhang, yangerkun

From: Yu Kuai <yukuai3@huawei.com>

Commit 99d055b4fd4b ("block: remove per-disk debugfs files in
blk_unregister_queue") moves blk_trace_shutdown() from
blk_release_queue() to blk_unregister_queue(), this is safe if blktrace
is created through sysfs, however, there is a regression in corner
case.

blktrace can still be enabled after del_gendisk() through ioctl if
the disk is opened before del_gendisk(), and if blktrace is not shutdown
through ioctl before closing the disk, debugfs entries will be leaked.

Fix this problem by shutdown blktrace in disk_release(), this is safe
because blk_trace_shutdown() is reentrant.

Noted that scsi sg can support blktrace without gendisk and still need
special handling to avoid this problem.

Fixes: 99d055b4fd4b ("block: remove per-disk debugfs files in blk_unregister_queue")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
---
 block/genhd.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

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
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH -next v2] block: fix blktrace debugfs entries leak
  2023-05-31  9:26 [PATCH -next v2] block: fix blktrace debugfs entries leak Yu Kuai
  2023-05-31  9:26 ` Yu Kuai
@ 2023-05-31 12:44 ` Christoph Hellwig
  2023-06-01  1:50   ` Yu Kuai
  1 sibling, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2023-05-31 12:44 UTC (permalink / raw)
  To: Yu Kuai; +Cc: hch, axboe, linux-block, linux-kernel, yukuai3, yi.zhang,
	yangerkun

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?


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH -next v2] block: fix blktrace debugfs entries leak
  2023-05-31 12:44 ` Christoph Hellwig
@ 2023-06-01  1:50   ` Yu Kuai
  2023-06-01  6:18     ` Christoph Hellwig
  0 siblings, 1 reply; 6+ messages in thread
From: Yu Kuai @ 2023-06-01  1:50 UTC (permalink / raw)
  To: Christoph Hellwig, Yu Kuai
  Cc: axboe, linux-block, linux-kernel, yi.zhang, yangerkun, yukuai (C)

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
> 
> 
> .
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH -next v2] block: fix blktrace debugfs entries leak
  2023-06-01  1:50   ` Yu Kuai
@ 2023-06-01  6:18     ` Christoph Hellwig
  2023-06-06  3:58       ` Yu Kuai
  0 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2023-06-01  6:18 UTC (permalink / raw)
  To: Yu Kuai
  Cc: Christoph Hellwig, axboe, linux-block, linux-kernel, yi.zhang,
	yangerkun, yukuai (C)

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.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH -next v2] block: fix blktrace debugfs entries leak
  2023-06-01  6:18     ` Christoph Hellwig
@ 2023-06-06  3:58       ` Yu Kuai
  0 siblings, 0 replies; 6+ messages in thread
From: Yu Kuai @ 2023-06-06  3:58 UTC (permalink / raw)
  To: Christoph Hellwig, Yu Kuai
  Cc: axboe, linux-block, linux-kernel, yi.zhang, yangerkun, yukuai (C)

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-06-06  3:58 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-05-31  9:26 [PATCH -next v2] block: fix blktrace debugfs entries leak Yu Kuai
2023-05-31  9:26 ` Yu Kuai
2023-05-31 12:44 ` Christoph Hellwig
2023-06-01  1:50   ` Yu Kuai
2023-06-01  6:18     ` Christoph Hellwig
2023-06-06  3:58       ` Yu Kuai

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox