Re: [PATCHv3 7/7] block: protect read_ahead_kb using q->limits_lock
From: Hannes Reinecke <hare@suse.de>
Date: 2025-02-25 11:43:52
On 2/25/25 11:18, Nilay Shroff wrote:
On 2/25/25 1:28 PM, Hannes Reinecke wrote:quoted
On 2/24/25 14:30, Nilay Shroff wrote:quoted
The bdi->ra_pages could be updated under q->limits_lock because it's usually calculated from the queue limits by queue_limits_commit_update. So protect reading/writing the sysfs attribute read_ahead_kb using q->limits_lock instead of q->sysfs_lock. Signed-off-by: Nilay Shroff <redacted> --- block/blk-sysfs.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c index 8f47d9f30fbf..228f81a9060f 100644 --- a/block/blk-sysfs.c +++ b/block/blk-sysfs.c@@ -93,9 +93,9 @@ static ssize_t queue_ra_show(struct gendisk *disk, char *page) { ssize_t ret; - mutex_lock(&disk->queue->sysfs_lock); + mutex_lock(&disk->queue->limits_lock); ret = queue_var_show(disk->bdi->ra_pages << (PAGE_SHIFT - 10), page); - mutex_unlock(&disk->queue->sysfs_lock); + mutex_unlock(&disk->queue->limits_lock); return ret; }@@ -111,12 +111,15 @@ queue_ra_store(struct gendisk *disk, const char *page, size_t count) ret = queue_var_store(&ra_kb, page, count); if (ret < 0) return ret; - - mutex_lock(&q->sysfs_lock); + /* + * ->ra_pages is protected by ->limits_lock because it is usually + * calculated from the queue limits by queue_limits_commit_update. + */ + mutex_lock(&q->limits_lock); memflags = blk_mq_freeze_queue(q); disk->bdi->ra_pages = ra_kb >> (PAGE_SHIFT - 10); + mutex_unlock(&q->limits_lock); blk_mq_unfreeze_queue(q, memflags); - mutex_unlock(&q->sysfs_lock);Cf my comments to the previous patch: Ordering. Here we take the lock _before_ 'freeze', with the previous patch we took the lock _after_ 'freeze'. Why?Yes this is ->limits_lock which is different from ->elevator_lock. The ->limits_lock is used by atomic update APIs queue_limits_start_update() and helpers. Here, the order we follow is : acquire ->limits_lock followed by queue-freeze. So even here in sysfs attribute store method we follow the same locking order.
Ah. Okay. Reviewed-by: Hannes Reinecke <hare@suse.de> Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich