Re: [PATCH] block: Fix a deadlock related to modifying the readahead attribute

[Nilay Shroff <nilay@linux.ibm.com>]

On 6/27/25 8:40 PM, Bart Van Assche wrote:
> On 6/26/25 11:16 PM, Nilay Shroff wrote:
>> Thanks! this makes sense now. But then we do have few other limits
>> (e.g. iostats_passthrough, iostats, write_cache etc.) which are accessed
>> during IO hotpath. So if we were to update those limits then we acquire
>> ->limits_lock and also freezes the queue. So I wonder how could those be
>> addressed?
> 
> Is there any Linux distro that sets these sysfs attributes from a udev
> rule? If not, I don't think that we have to worry about these sysfs
> attributes.
> 

I think that's not only about distro udev rules setting queue limits.
It's quite possible that some user applications may programmatically update
these queue limits during runtime. In such cases, the application would need
to freeze the queue before making changes. So even if no current distro sets
these attributes via udev, that could change in the future, and we don't have
control over that.

Looking at your earlier dmsetup command:
# dmsetup table mpatha
0 65536 multipath 1 queue_if_no_path 1 alua 1 1 service-time 0 1 2 8:32 1 1 

In the above rule, the option queue_if_no_path seems bit odd (unless used 
with timeout). Can't we add module param queue_if_no_path_timeout_secs=<N>
while loading dm-multipath and thus avoid hanging the queue I/O indefinitely 
when all paths of a multipath device is lost? IMO, queue_if_no_path without
timeout may make sense when we know that the paths will eventually recover 
and that applications should simply wait.

Thanks,
--Nilay