Re: [PATCH 1/2] block: Revert "block: Fix potential deadlock while freezing queue and acquiring sysfs_lock"

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

On 12/20/24 20:54, Ming Lei wrote:
> On Fri, Dec 20, 2024 at 11:10 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 12/20/24 3:23 AM, Nilay Shroff wrote:
>>> On 12/18/24 15:46, Ming Lei wrote:
>>>> This reverts commit be26ba96421ab0a8fa2055ccf7db7832a13c44d2.
>>>>
>>>> Commit be26ba96421a ("block: Fix potential deadlock while freezing queue and
>>>> acquiring sysfs_loc") actually reverts commit 22465bbac53c ("blk-mq: move cpuhp
>>>> callback registering out of q->sysfs_lock"), and causes the original resctrl
>>>> lockdep warning.
>>>>
>>>> So revert it and we need to fix the issue in another way.
>>>>
>>> Hi Ming,
>>>
>>> Can we wait here for some more time before we revert this as this is
>>> currently being discussed[1] and we don't know yet how we may fix it?
>>>
>>> [1]https://lore.kernel.org/all/20241219061514.GA19575@lst.de/
>>
>> It's already queued up and will go out today. Doesn't exclude people
>> working on solving this for real.
> 
> IMO, it is correct to cut the dependency between q->sysfs_lock and
> global cpu hotplug lock, otherwise more subsystems can be involved,
> so let's revert it first.
> 
Yeah agreed, we may want to in that case just remove lockdep aseert of 
q->sysfs_lock from blk_mq_realloc_hw_ctxs() and also remove q->sysfs_lock 
from blk_mq_init_allocated_queue(). But that's ok. Lets see how we'd pursue 
further and solve other limits-lock and queue-freeze issue. 

> Christoph is also working on q->sysfs_lock warning, and we can try to
> figure out other solutions given the involved(or most of) locks should be
> from block layer internal.
> 
> https://lore.kernel.org/linux-block/20241219061514.GA19575@lst.de/
> 
 
Thanks,
--Nilay