From: Christoph Hellwig <hch@lst.de>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: hch@lst.de, ming.lei@redhat.com, axboe@kernel.dk,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
yukuai3@huawei.com, yi.zhang@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH -next] block: fix blktrace debugfs entries leak
Date: Thu, 11 May 2023 17:28:08 +0200 [thread overview]
Message-ID: <20230511152808.GA8641@lst.de> (raw)
In-Reply-To: <20230511065633.710045-1-yukuai1@huaweicloud.com>
On Thu, May 11, 2023 at 02:56:33PM +0800, Yu Kuai wrote:
> 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 are some regression in corner
> cases:
>
> 1) for scsi, passthrough io can still be issued after del_gendisk, and
> blktrace debugfs entries will be removed immediately after
> del_gendisk(), therefor passthrough io can't be tracked and blktrace
> will complain:
>
> failed read of /sys/kernel/debug/block/sdb/trace0: 5/Input/output error
But that is the right thing. The only thing that has a name is the
gendisk and it is gone at this point. Leaking the debugfs entries
that are named after, and ultimatively associated with the gendisk
(even if the code is still a bit confused about this) will create a lot
of trouble for us.
> 2) 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.
Yes.
> It seems 1) is not important, while 2) needs to be fixed apparently.
>
> Fix this problem by shutdown blktrace in blk_free_queue(),
> disk_release() is not used because scsi sg support blktrace without
> gendisk, and this is safe because queue is not freed yet, and
> blk_trace_shutdown() is reentrant.
I think disk_release is the right place for "normal" blktrace. The
odd cdev based blktrace for /dev/sg will need separate handling.
To be honest I'm not even sure how /dev/sg based passthrough is
even supposed to work in practice, but I'll need to spend some more
time to familarize myself with it.
next prev parent reply other threads:[~2023-05-11 15:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 6:56 [PATCH -next] block: fix blktrace debugfs entries leak Yu Kuai
2023-05-11 15:28 ` Christoph Hellwig [this message]
2023-05-12 7:14 ` Yu Kuai
2023-05-30 2:07 ` Yu Kuai
2023-05-30 14:29 ` Christoph Hellwig
2023-05-31 7:42 ` Yu Kuai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230511152808.GA8641@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox