Re: [PATCHv5 1/7] block: acquire q->limits_lock while reading sysfs attributes

[Ming Lei <ming.lei@redhat.com>]

On Wed, Feb 26, 2025 at 06:09:54PM +0530, Nilay Shroff wrote:
> There're few sysfs attributes(RW) whose store method is protected
> with q->limits_lock, however the corresponding show method of these
> attributes run holding q->sysfs_lock and that doesn't make sense
> as ideally the show method of these attributes should also run
> holding q->limits_lock instead of q->sysfs_lock. Hence update the
> show method of these sysfs attributes so that reading of these
> attributes acquire q->limits_lock instead of q->sysfs_lock.
> 
> Similarly, there're few sysfs attributes(RO) whose show method is
> currently protected with q->sysfs_lock however updates to these
> attributes could occur using atomic limit update APIs such as queue_
> limits_start_update() and queue_limits_commit_update() which run
> holding q->limits_lock. So that means that reading these attributes
> holding q->sysfs_lock doesn't make sense. Hence update the show method
> of these sysfs attributes(RO) such that they run with holding q->
> limits_lock instead of q->sysfs_lock.
> 
> We have defined a new macro QUEUE_LIM_RO_ENTRY() which uses new ->show_
> limit() method and it runs holding q->limits_lock. All existing sysfs
> attributes(RO) which needs protection using q->limits_lock while
> reading have been now updated to use this new macro for initialization.
> 
> Also, the existing QUEUE_LIM_RW_ENTRY() is updated to use new ->show_
> limit() method for reading attributes instead of existing ->show()
> method. As ->show_limit() runs holding q->limits_lock, the existing
> sysfs attributes(RW) requiring protection are now inherently protected
> using q->limits_lock instead of q->sysfs_lock.
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Reviewed-by: Hannes Reinecke <hare@suse.de>
> Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>

Reviewed-by: Ming Lei <ming.lei@redhat.com>


Thanks,
Ming