On 2/24/25 14:30, Nilay Shroff wrote:
The wbt latency and state could be updated while initializing the
elevator or exiting the elevator. It could be also updates while
configuring IO latency QoS parameters using cgroup. The elevator
code path is now protected with q->elevator_lock. So we should
protect the access to sysfs attribute wbt_lat_usec using q->elevator
_lock instead of q->sysfs_lock. White we're at it, also protect
ioc_qos_write(), which configures wbt parameters via cgroup, using
q->elevator_lock.
Signed-off-by: Nilay Shroff <nilay@xxxxxxxxxxxxx>
---
block/blk-iocost.c | 2 ++
block/blk-sysfs.c | 20 ++++++++------------
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/block/blk-iocost.c b/block/blk-iocost.c
index 65a1d4427ccf..c68373361301 100644
--- a/block/blk-iocost.c
+++ b/block/blk-iocost.c
@@ -3249,6 +3249,7 @@ static ssize_t ioc_qos_write(struct kernfs_open_file *of, char *input,
}
memflags = blk_mq_freeze_queue(disk->queue);
+ mutex_lock(&disk->queue->elevator_lock);
blk_mq_quiesce_queue(disk->queue);
Ordering?
Do we have a defined order between 'freeze', 'quiesce' and taking the
respective lock?
Or, to put it the other way round: why do we tak the lock after the
'freeze', but before the 'quiesce'?
Isn't that worth a comment somewhere?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +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
