From: Nilay Shroff <nilay@linux.ibm.com>
To: linux-block@vger.kernel.org
Cc: hch@lst.de, ming.lei@redhat.com, dlemoal@kernel.org,
hare@suse.de, axboe@kernel.dk, gjoyce@ibm.com
Subject: [PATCHv4 0/7] block: fix lock order and remove redundant locking
Date: Tue, 25 Feb 2025 19:00:35 +0530 [thread overview]
Message-ID: <20250225133110.1441035-1-nilay@linux.ibm.com> (raw)
Hi,
After we modeled the freeze & enter queue as lock for supporting lockdep
under commit f1be1788a32e ("block: model freeze & enter queue as lock
for supporting lockdep"), we received numerous lockdep splats. And one
of those splats[1] reported the potential deadlock due to incorrect lock
ordering issue between q->sysfs-lock and q->q_usage_counter. So some of
the patches in this series are aimed to cut the dependency between q->
sysfs-lock and q->q_usage_counter.
This patchset contains seven patches in the series.
The 1st patch helps acquire q->limits_lock instead of q->sysfs_lock while
reading a set of attributes whose write method is protected with atomic
limit update APIs or updates to these attributes could occur under atomic
limit update APIs such as queue_limit_start_update() and queue_limits_
commit_update(). So all such attributes have been now grouped in queue_
attr_show under ->show_limit() method.
The 2nd patch is preparation to further simplify and group sysfs attributes
in subsequent patches. So in this patch we move acquire/release of q->sysfs
_lock as well as queue freeze/unfreeze under each attributes' respective
->show()/->store() method.
The 3rd patch removes the q->sysfs_lock for all sysfs attributes which
don't need it. We identified all sysfs attributes which don't need any
locking and removed use of q->sysfs_lock for these attributes.
Subsequent patches address remaining attributes individually which require
some form of locking other than q->limits_lock or q->sysfs_lock.
The 4th patch introduce a new dedicated lock for elevator switch/update
and thus eliminates the dependency of sched update on q->sysfs_lock.
The 5th patch protects sysfs attribute nr_requests using q->elevator_lock
instead of q->sysfs_lock as the update to q->nr_requests now happen under
q->elevator_lock.
Similarly, the 6th patch protects sysfs attribute wbt_lat_usec using
q->elevator_lock instead of q->sysfs_lock as the update to wbt state and
latency now happen under q->elevator_lock.
The 7th patch protects read_ahead_kb using q->limits_lock instead of
q->sysfs_lock as update to ->ra_pages is protected by ->limits_lock.
The ->ra_pages is usually calculated from the queue limits by queue_
limits_commit_update.
Please note that above changes were unit tested against blktests and
quick xfstests with lockdep enabled.
[1] https://lore.kernel.org/all/67637e70.050a0220.3157ee.000c.GAE@google.com/
---
Changes from v3:
- Make code comment a proper senteence. Also mention the
fields protected by q->elevator_lock (hch)
- Add a comment describing lock ordering followed for
newly introduced ->elevator_lock (Hannes Reinecke)
Link to v3: https://lore.kernel.org/all/20250224133102.1240146-1-nilay@linux.ibm.com/
Changes from v2:
- Add a prep patch (second patch in the series) to first move q->sysfs_
lock and queue freeze from queue_attr_show/queue_attr_store to show/
store method of the respective attribute; then in subsequent patches
we remove q->sysfs_lock from attributes that don't require any from of
locking or replace q->sysfs_lock with appropriate lock for attributes
that require some form of locking; this way we can get away with using
->show_nolock()/->store_nolock() methods (hch)
- Few other misc updates to commit message and code comments (hch)
- Rearrange the patchset to improve organization and clarity. Start with
a patch that groups all attributes requiring protection under ->limits_
lock. Follow this with a preparatory patch, then introduce a patch that
consolidates attributes that do not require any form of locking.
Finally, address the remaining attributes individually in subsequent
patches, which require some form of locking other than q->limits_lock
or q->sysfs_lock.
Link to v2: https://lore.kernel.org/all/20250218082908.265283-1-nilay@linux.ibm.com/
Changes from v1:
- Audit all sysfs attributes in block layer and find attributes which
don't need any locking as well as attributes which needs some form of
locking; then remove locking from queue_attr_store/queue_attr_show and
move it into the attributes that still need it in some form, followed
by replacing it with the more suitable locks (hch)
- Use dedicated lock for elevator switch/update (Ming Lei)
- Re-arrange patchset to first segregate and group together all
attributes which don't need locking followed by grouping attributes
which need some form of locking.
Link to v1: https://lore.kernel.org/all/20250205144506.663819-1-nilay@linux.ibm.com/
---
Nilay Shroff (7):
block: acquire q->limits_lock while reading sysfs attributes
block: move q->sysfs_lock and queue-freeze under show/store method
block: remove q->sysfs_lock for attributes which don't need it
block: Introduce a dedicated lock for protecting queue elevator
updates
block: protect nr_requests update using q->elevator_lock
block: protect wbt_lat_usec using q->elevator_lock
block: protect read_ahead_kb using q->limits_lock
block/blk-core.c | 1 +
block/blk-iocost.c | 2 +
block/blk-mq.c | 15 +-
block/blk-settings.c | 2 +-
block/blk-sysfs.c | 309 +++++++++++++++++++++++++++--------------
block/elevator.c | 43 ++++--
block/elevator.h | 2 -
block/genhd.c | 9 +-
include/linux/blkdev.h | 8 ++
9 files changed, 254 insertions(+), 137 deletions(-)
--
2.47.1
next reply other threads:[~2025-02-25 13:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-25 13:30 Nilay Shroff [this message]
2025-02-25 13:30 ` [PATCHv4 1/7] block: acquire q->limits_lock while reading sysfs attributes Nilay Shroff
2025-02-25 13:30 ` [PATCHv4 2/7] block: move q->sysfs_lock and queue-freeze under show/store method Nilay Shroff
2025-02-25 13:30 ` [PATCHv4 3/7] block: remove q->sysfs_lock for attributes which don't need it Nilay Shroff
2025-02-25 13:30 ` [PATCHv4 4/7] block: Introduce a dedicated lock for protecting queue elevator updates Nilay Shroff
2025-02-25 15:12 ` Christoph Hellwig
2025-02-26 12:12 ` Nilay Shroff
2025-02-25 13:30 ` [PATCHv4 5/7] block: protect nr_requests update using q->elevator_lock Nilay Shroff
2025-02-25 13:30 ` [PATCHv4 6/7] block: protect wbt_lat_usec " Nilay Shroff
2025-02-25 15:13 ` Christoph Hellwig
2025-02-26 12:11 ` Nilay Shroff
2025-02-26 7:33 ` Hannes Reinecke
2025-02-25 13:30 ` [PATCHv4 7/7] block: protect read_ahead_kb using q->limits_lock Nilay Shroff
2025-02-25 15:14 ` Christoph Hellwig
2025-02-26 12:10 ` Nilay Shroff
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=20250225133110.1441035-1-nilay@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=axboe@kernel.dk \
--cc=dlemoal@kernel.org \
--cc=gjoyce@ibm.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.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 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.