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

[Shin'ichiro Kawasaki]

On Oct 23, 2026 / 13:17, 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. That is what breaks the udev rules that set the scheduler 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, so use a new mutex for that instead. It is held across
> elevator_change(), and only the sysfs store takes it. The other callers
> of elevator_change() run before the queue is registered, after its sysfs
> files are gone, or with the lock held for write, so they cannot race
> with the store.
> 
> nr_hw_queues updates, nr_requests writes and disk removal still take the
> lock for write, so a scheduler write can still get -EBUSY while one of
> those holds or waits for it, as before 4ff58d6bc9dd.
> 
> Fixes: 4ff58d6bc9dd ("block: serialize elevator changes for the same queue using a writer lock")
> Cc: stable@xxxxxxxxxxxxxxx # v7.2+
> Reported-by: Reindl Harald <h.reindl@xxxxxxxxxxxxx>
> Closes: https://lore.kernel.org/r/077dd42e-cbc9-4c23-a5ef-3d20e4fc7757@xxxxxxxxxxxxx
> Assisted-by: LLM
> Signed-off-by: Laveesh Bansal <laveeshb@xxxxxxxxxxxxxxxxx>

FYI, this patch looks similar as the RFC patch that I created before [*]. It
adds another mutex in similar manner as this patch.

[*] https://lore.kernel.org/linux-block/aiqaXfTqCLMu2DwF@fedora/

I ran whole blktests applying this patch on top of the kernel v7.3. I observed
no regression, then looks good from testing point of view. In case this patch
gets applied,

Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@xxxxxxx>