Re: [REPORT] Possible circular locking dependency on 6.18-rc2 in blkg_conf_open_bdev_frozen+0x80/0xa0

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

On 10/29/25 1:55 PM, Ming Lei wrote:
> On Tue, Oct 28, 2025 at 06:36:20PM +0530, Nilay Shroff wrote:
>>
>>
>> On 10/28/25 2:00 AM, Bart Van Assche wrote:
>>> On 10/23/25 9:54 PM, Nilay Shroff wrote:
>>>> IMO, we need to make lockdep learn about this differences by assigning separate
>>>> lockdep key/class for each queue's q->debugfs_mutex to avoid this false positive.
>>>> As this is another report with the same false-positive lockdep splat, I think we
>>>> should address this.
>>>>
>>>> Any other thoughts or suggestions from others on the list?
>>>
>>> Please take a look at lockdep_register_key() and
>>> lockdep_unregister_key(). I introduced these functions six years ago to
>>> suppress false positive lockdep complaints like this one.
>>>
>> Thanks Bart! I'll send out patch with the above proposed fix.
> 
> IMO, that may not be a smart approach, here the following dependency should
> be cut:
> #4 (&q->q_usage_counter(io)#2){++++}-{0:0}:
> 
> ...
> 
> #1 (&q->debugfs_mutex){+.+.}-{4:4}:
> #0 (&q->rq_qos_mutex){+.+.}-{4:4}:
> 
> Why is there the dependency between `#1 (&q->debugfs_mutex)` and `#0 (&q->rq_qos_mutex)`?
> 
Okay this also makes sense: if we could remove the ->rq_qos_mutex depedency on
->debug_fs_mutex. However I also think lockdep may, even after cutting depedency,
still generate spurious splat (due to it's not able to distinguish between 
distinct ->debugfs_mutex instances). We may check that letter if that really
happens.  

> I remember that Yu Kuai is working on remove it:
> 
> https://lore.kernel.org/linux-block/20251014022149.947800-1-yukuai3@huawei.com/
> 
Let me add Yu Kuai in the Cc. BTW, of late I saw my emails to Yu are bouncing.
But I found another email of Yu from lore, so I am adding it here - hope, this
is the correct email.

Thanks,
--Nilay