From: Jens Axboe <axboe@kernel.dk>
To: Bart Van Assche <Bart.VanAssche@sandisk.com>,
"ming.lei@redhat.com" <ming.lei@redhat.com>
Cc: "hch@lst.de" <hch@lst.de>, "osandov@fb.com" <osandov@fb.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"hare@suse.com" <hare@suse.com>
Subject: Re: [PATCH 4/5] blk-mq-debugfs: Show busy requests
Date: Tue, 30 May 2017 11:32:26 -0600 [thread overview]
Message-ID: <2c6537c7-591c-0663-8271-7120fe7c9336@kernel.dk> (raw)
In-Reply-To: <1496165077.2627.15.camel@sandisk.com>
On 05/30/2017 11:24 AM, Bart Van Assche wrote:
>> [ ... ]
>> During this small window, the request can be freed and reallocated
>> in another I/O path, then use-after-free is caused.
>
> A similar remark applies to all request queue debugfs attributes: the
> queue state can change immediately after having queried the state so
> that's not unique to this attribute. Regarding the "use-after-free":
> the memory that is allocated for requests is only freed after the
> debugfs attributes have been removed so the code that implements this
> attribute will read the contents of a struct request. It is up to the
> person who reads the contents of this attribute to decide how to
> interpret the contents.
I think it's important to stress that the memory is not going away, so
it'll potentially just show a new state of the request. That's perfectly
fine, and will happen all the time for the various debugfs exports. The
useful aspect of them is when things have come to a halt, for whatever
reason. The states will tend to stay stable when that happens, and
provide a useful method of introspection to debug the issue.
The important part here is that the memory is perfectly valid, so we
won't run into issues with that.
--
Jens Axboe
next prev parent reply other threads:[~2017-05-30 17:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-25 23:38 [PATCH 0/5] Five blk-mq-debugfs patches Bart Van Assche
2017-05-25 23:38 ` [PATCH 1/5] blk-mq: Only register debugfs attributes for blk-mq queues Bart Van Assche
2017-05-26 0:23 ` Omar Sandoval
2017-05-26 5:56 ` Hannes Reinecke
2017-05-26 13:27 ` Jens Axboe
2017-05-25 23:38 ` [PATCH 2/5] blk-mq-debugfs: Show atomic request flags Bart Van Assche
2017-05-26 5:56 ` Hannes Reinecke
2017-05-25 23:38 ` [PATCH 3/5] blk-mq-debugfs: Show requeue list Bart Van Assche
2017-05-26 5:57 ` Hannes Reinecke
2017-05-25 23:38 ` [PATCH 4/5] blk-mq-debugfs: Show busy requests Bart Van Assche
2017-05-26 13:26 ` Jens Axboe
2017-05-26 21:17 ` Bart Van Assche
2017-05-26 21:20 ` Jens Axboe
2017-05-26 21:21 ` Jens Axboe
2017-05-26 21:22 ` Bart Van Assche
2017-05-26 14:38 ` Hannes Reinecke
2017-05-26 21:27 ` Bart Van Assche
2017-05-26 21:32 ` Jens Axboe
2017-05-27 0:54 ` Ming Lei
2017-05-27 3:16 ` Ming Lei
2017-05-30 17:29 ` Bart Van Assche
2017-05-30 17:24 ` Bart Van Assche
2017-05-30 17:32 ` Jens Axboe [this message]
2017-05-25 23:38 ` [PATCH 5/5] blk-mq-debugfs: Add 'kick' operation Bart Van Assche
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=2c6537c7-591c-0663-8271-7120fe7c9336@kernel.dk \
--to=axboe@kernel.dk \
--cc=Bart.VanAssche@sandisk.com \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=osandov@fb.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