On Thu, 12 Sept 2024 at 15:44, Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> Just a single fix for a deadlock issue that can happen if someone
> attempts to change the root disk IO scheduler with a module that
> requires loading from disk. Changing the scheduler freezes the queue
> while that operation is happening, hence causing a deadlock.
Side note: I do think that doing the blk_mq_freeze_queue() outside the
sysfs_lock mutex is also a mistake, and will deadlock if anybody then
needs to do any IO (like a user space access) inside the sysfs_lock
mutex somewhere else.
It wasn't what caused Jesper's problems, and maybe nothing actually
does that, but it still looks rather questionable in
queue_attr_store().
I mean, imagine holding q->sysfs_lock, and doing something as simple
as just a memory allocation that wants to do swapping, but somebody
else did that queue_attr_store(), which freezed the queues and is now
waiting for the lock and won't unfreeze them until it gets it...
Yeah, yeah, very very unlikely to hit in real life, but still. Seems very wrong.
Linus
