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@xxxxxx> > Reviewed-by: Hannes Reinecke <hare@xxxxxxx> > Signed-off-by: Nilay Shroff <nilay@xxxxxxxxxxxxx> Reviewed-by: Ming Lei <ming.lei@xxxxxxxxxx> Thanks, Ming
