From: Ming Lei <ming.lei@redhat.com>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@kernel.org>,
Sagi Grimberg <sagi@grimberg.me>,
Nilay Shroff <nilay@linux.ibm.com>
Subject: Re: [PATCH 1/3] block: Fix sysfs queue freeze and limits lock order
Date: Mon, 6 Jan 2025 11:40:22 +0800 [thread overview]
Message-ID: <Z3tQpt7n-NdSDN13@fedora> (raw)
In-Reply-To: <ae75194f-334f-4337-b1e6-e68b8d63bc93@kernel.org>
On Mon, Jan 06, 2025 at 12:35:36PM +0900, Damien Le Moal wrote:
> On 1/6/25 12:31 PM, Ming Lei wrote:
> > On Sat, Jan 04, 2025 at 10:25:20PM +0900, Damien Le Moal wrote:
> >> queue_attr_store() always freezes a device queue before calling the
> >> attribute store operation. For attributes that control queue limits, the
> >> store operation will also lock the queue limits with a call to
> >> queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may
> >> need to issue commands to a device to obtain limit values from the
> >> hardware with the queue limits locked. This creates a potential ABBA
> >> deadlock situation if a user attempts to modify a limit (thus freezing
> >> the device queue) while the device driver starts a revalidation of the
> >> device queue limits.
> >>
> >> Avoid such deadlock by introducing the ->store_limit() operation in
> >> struct queue_sysfs_entry and use this operation for all attributes that
> >> modify the device queue limits through the QUEUE_RW_LIMIT_ENTRY() macro
> >> definition. queue_attr_store() is modified to call the ->store_limit()
> >> operation (if it is defined) without the device queue frozen. The device
> >> queue freeze for attributes defining the ->stor_limit() operation is
> >> moved to after the operation completes and is done only around the call
> >> to queue_limits_commit_update().
> >>
> >> Cc: stable@vger.kernel.org # v6.9+
> >> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> >> ---
> >> block/blk-sysfs.c | 123 ++++++++++++++++++++++++----------------------
> >> 1 file changed, 64 insertions(+), 59 deletions(-)
> >>
> >> diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
> >> index 767598e719ab..4fc0020c73a5 100644
> >> --- a/block/blk-sysfs.c
> >> +++ b/block/blk-sysfs.c
> >> @@ -24,6 +24,8 @@ struct queue_sysfs_entry {
> >> struct attribute attr;
> >> ssize_t (*show)(struct gendisk *disk, char *page);
> >> ssize_t (*store)(struct gendisk *disk, const char *page, size_t count);
> >> + ssize_t (*store_limit)(struct gendisk *disk, struct queue_limits *lim,
> >> + const char *page, size_t count);
> >
> > As I mentioned in another thread, freezing queue may not be needed in
> > ->store(), so let's discuss and confirm if it is needed here first.
> >
> > https://lore.kernel.org/linux-block/Z3tHozKiUqWr7gjO@fedora/
> >
> > Also even though freeze is needed, I'd suggest to move freeze in each
> > .store() callback for simplifying & avoiding regression.
>
> The patch would be simpler, sure. But the code would not be simpler in my
> opinion as we will repeat the freeze+limits commit+unfreeze pattern in several
> callbacks. That is why I made the change to introduce the new store_limit()
> callback to have that pattern in a single place.
>
> And thinking about it, queue_attr_store() should be better commented to clearly
> describes the locking rules.
The pattern can be enhanced by one new helper or API.
But let's discuss if we really need the pattern first.
IMO, freeze isn't needed in ->store().
Thanks,
Ming
next prev parent reply other threads:[~2025-01-06 3:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-04 13:25 [PATCH 0/3] Fix queue freeze and limit locking order Damien Le Moal
2025-01-04 13:25 ` [PATCH 1/3] block: Fix sysfs queue freeze and limits lock order Damien Le Moal
2025-01-04 16:26 ` Nilay Shroff
2025-01-06 8:27 ` Christoph Hellwig
2025-01-06 3:31 ` Ming Lei
2025-01-06 3:35 ` Damien Le Moal
2025-01-06 3:40 ` Ming Lei [this message]
2025-01-06 8:29 ` Christoph Hellwig
2025-01-06 11:15 ` Ming Lei
2025-01-06 15:29 ` Christoph Hellwig
2025-01-07 0:45 ` Ming Lei
2025-01-07 6:18 ` Christoph Hellwig
2025-01-06 8:25 ` Christoph Hellwig
2025-01-04 13:25 ` [PATCH 2/3] block: Fix __blk_mq_update_nr_hw_queues() " Damien Le Moal
2025-01-06 8:30 ` Christoph Hellwig
2025-01-06 9:58 ` Damien Le Moal
2025-01-06 10:00 ` Christoph Hellwig
2025-01-04 13:25 ` [PATCH 3/3] nvme: Fix " Damien Le Moal
2025-01-06 8:31 ` Christoph Hellwig
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=Z3tQpt7n-NdSDN13@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=dlemoal@kernel.org \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nilay@linux.ibm.com \
--cc=sagi@grimberg.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.