block: protect nr_requests update using q->elevator_lock

The sysfs attribute nr_requests could be simultaneously updated from
elevator switch/update or nr_hw_queue update code path. The update to
nr_requests for each of those code paths runs holding q->elevator_lock.
So we should protect access to sysfs attribute nr_requests using q->
elevator_lock instead of q->sysfs_lock.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
Link: https://lore.kernel.org/r/20250304102551.2533767-6-nilay@linux.ibm.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This commit is contained in:
Nilay Shroff
2025-03-04 15:52:34 +05:30
committed by Jens Axboe
parent 1bf70d08cc
commit 3efe7571c3
2 changed files with 11 additions and 9 deletions

View File

@@ -561,10 +561,12 @@ struct request_queue {
struct list_head flush_list;
/*
* Protects against I/O scheduler switching, specifically when
* updating q->elevator. To ensure proper locking order during
* an elevator update, first freeze the queue, then acquire
* ->elevator_lock.
* Protects against I/O scheduler switching, particularly when
* updating q->elevator. Since the elevator update code path may
* also modify q->nr_requests, this lock also protects the sysfs
* attribute nr_requests.
* To ensure proper locking order during an elevator update, first
* freeze the queue, then acquire ->elevator_lock.
*/
struct mutex elevator_lock;