On 11/10/25 9:54 PM, Bart Van Assche wrote:
Freezing the request queue from inside sysfs store callbacks may cause a deadlock in combination with the dm-multipath driver and the queue_if_no_path option. Additionally, freezing the request queue slows down system boot on systems where sysfs attributes are set synchronously.
Fix this by removing the blk_mq_freeze_queue() / blk_mq_unfreeze_queue() calls from the store callbacks that do not strictly need these callbacks. This patch may cause a small delay in applying the new settings.
This patch affects the following sysfs attributes:
- io_poll_delay
- io_timeout
- nomerges
- read_ahead_kb
- rq_affinity
I applied your patch on my linux tree and ran some tests. And as I earlier suspected, I found the following race from KCSAN:
1. Running q->io_timeout update concurrently while running I/O:
BUG: KCSAN: data-race in blk_add_timer+0x64/0x1cc
race at unknown origin, with read to 0xc000000142575fa8 of 4 bytes by task 5528 on cpu 49: blk_add_timer+0x64/0x1cc blk_mq_start_request+0xd0/0x534 nvme_prep_rq.part.0+0x55c/0x1940 [nvme] nvme_queue_rqs+0x1e0/0x4c4 [nvme] blk_mq_dispatch_queue_requests+0x4f0/0x8c0 blk_mq_flush_plug_list+0xb4/0x3cc __blk_flush_plug+0x294/0x358 __submit_bio+0x308/0x3a4 submit_bio_noacct_nocheck+0x5e4/0x92c submit_bio_noacct+0x3a4/0xec8 submit_bio+0x70/0x2f0 submit_bio_wait+0xc8/0x180 __blkdev_direct_IO_simple+0x254/0x4a8 blkdev_direct_IO+0x6d4/0x1000 blkdev_write_iter+0x50c/0x658 vfs_write+0x678/0x874 sys_pwrite64+0x130/0x16c system_call_exception+0x1a0/0x500 system_call_vectored_common+0x15c/0x2ec
value changed: 0x000005dc -> 0x00000bb8
Reported by Kernel Concurrency Sanitizer on: CPU: 49 UID: 0 PID: 5528 Comm: fio Kdump: loaded Not tainted 6.18.0-rc4+ #65 VOLUNTARY Hardware name: IBM,9105-22A Power11 (architected) 0x820200 0xf000007 of:IBM,FW1120.00 (RB1120_115) hv:phyp pSeries
2. Updating ->ra_pages while it's also being simultaneously accessed:
BUG: KCSAN: data-race in queue_ra_show / read_ahead_kb_store
write to 0xc00000000c107030 of 8 bytes by task 97376 on cpu 19: read_ahead_kb_store+0x84/0xcc dev_attr_store+0x70/0x9c sysfs_kf_write+0xbc/0x110 kernfs_fop_write_iter+0x284/0x3b4 vfs_write+0x678/0x874 ksys_write+0xb0/0x1ac sys_write+0x68/0x84 system_call_exception+0x1a0/0x500 system_call_vectored_common+0x15c/0x2ec
read to 0xc00000000c107030 of 8 bytes by task 167534 on cpu 33: queue_ra_show+0x70/0xd4 queue_attr_show+0x90/0x170 sysfs_kf_seq_show+0x144/0x28c kernfs_seq_show+0xbc/0xe0 seq_read_iter+0x384/0xb4c kernfs_fop_read_iter+0x308/0x418 vfs_read+0x420/0x5ac ksys_read+0xb0/0x1b0 sys_read+0x68/0x84 system_call_exception+0x1a0/0x500 system_call_vectored_common+0x15c/0x2ec
value changed: 0x0000000000000004 -> 0x0000000000000010
Reported by Kernel Concurrency Sanitizer on: CPU: 33 UID: 0 PID: 167534 Comm: cat Kdump: loaded Not tainted 6.18.0-rc4+ #65 VOLUNTARY Hardware name: IBM,9105-22A Power11 (architected) 0x820200 0xf000007 of:IBM,FW1120.00 (RB1120_115) hv:phyp pSeries
So from the above trace it seems obvious that we need to mark both writers and readers to avoid potential race.
Thanks, --Nilay