Re: [PATCH v2] block: only serialize elevator switches of the same queue

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

On 10/31/26 10:11 AM, Laveesh Bansal wrote:
> Since commit 4ff58d6bc9dd ("block: serialize elevator changes for the
> same queue using a writer lock"), a write to queue/scheduler fails with
> -EBUSY whenever something else holds set->update_nr_hwq_lock. That
> commit takes the lock for write, and it has to be a trylock because of
> commit ce8ee8583ed8 ("block: use trylock to avoid lockdep circular
> dependency in sysfs").
> 
> The lock covers the whole tag set, so it is easy to hit. A scheduler
> write fails while another queue of the set is switching, or while a
> sibling disk of the same SCSI host or NVMe controller is added or
> removed. This matches the udev failures reported on 7.2.
> 
> Go back to taking the lock for read. The write lock was there to keep
> two switches of one queue from overlapping in elevator_change_done(),
> which touches the elevator sysfs and debugfs entries outside of
> q->elevator_lock. Use QUEUE_FLAG_NO_ELV_SWITCH for that instead: a
> write sets it before elevator_change() and clears it afterwards, and a
> write that finds it set returns -EBUSY. Disk removal already sets the
> flag under the write lock, so no switch can start once it has run.
> 
> Writes to the same queue, and writes that race with an nr_hw_queues
> update, an nr_requests write or disk removal, can still get -EBUSY, as
> with 4ff58d6bc9dd. A write to a disk that is being removed now gets
> -EBUSY instead of -ENOENT.
> 
> Fixes: 4ff58d6bc9dd ("block: serialize elevator changes for the same queue using a writer lock")
> Cc:stable@vger.kernel.org # v7.2+
> Reported-by: Reindl Harald<h.reindl@thelounge.net>
> Closes:https://lore.kernel.org/r/077dd42e-cbc9-4c23-a5ef-3d20e4fc7757@thelounge.net
> Suggested-by: Nilay Shroff<nilay@linux.ibm.com>
> Assisted-by: LLM
> Signed-off-by: Laveesh Bansal<laveeshb@laveeshbansal.com>

Looks good to me:
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>