Re: Blockdev 6.13-rc lockdep splat regressions

[Ming Lei <ming.lei@redhat.com>]

On Fri, Jan 10, 2025 at 03:36:44PM +0100, Thomas Hellström wrote:
> On Fri, 2025-01-10 at 20:13 +0800, Ming Lei wrote:
> > On Fri, Jan 10, 2025 at 11:12:58AM +0100, Thomas Hellström wrote:
> > > Ming, Others
> > > 
> > > On 6.13-rc6 I'm seeing a couple of lockdep splats which appear
> > > introduced by the commit
> > > 
> > > f1be1788a32e ("block: model freeze & enter queue as lock for
> > > supporting
> > > lockdep")
> > 
> > The freeze lock connects all kinds of sub-system locks, that is why
> > we see lots of warnings after the commit is merged.
> > 
> > ...
> > 
> > > #1
> > > [  399.006581]
> > > ======================================================
> > > [  399.006756] WARNING: possible circular locking dependency
> > > detected
> > > [  399.006767] 6.12.0-rc4+ #1 Tainted: G     U           N
> > > [  399.006776] ----------------------------------------------------
> > > --
> > > [  399.006801] kswapd0/116 is trying to acquire lock:
> > > [  399.006810] ffff9a67a1284a28 (&q->q_usage_counter(io)){++++}-
> > > {0:0},
> > > at: __submit_bio+0xf0/0x1c0
> > > [  399.006845] 
> > >                but task is already holding lock:
> > > [  399.006856] ffffffff8a65bf00 (fs_reclaim){+.+.}-{0:0}, at:
> > > balance_pgdat+0xe2/0xa20
> > > [  399.006874] 
> > 
> > The above one is solved in for-6.14/block of block tree:
> > 
> > 	block: track queue dying state automatically for modeling
> > queue freeze lockdep
> 
> Hmm. I applied this series:
> 
> https://patchwork.kernel.org/project/linux-block/list/?series=912824&archive=both
> 
> on top of -rc6, but it didn't resolve that splat. Am I using the
> correct patches?
> 
> Perhaps it might be a good idea to reclaim-prime those lockdep maps
> taken during reclaim to have the splats happen earlier.

for-6.14/block does kill the dependency between fs_reclaim and
q->q_usage_counter(io) in scsi_add_lun() when scsi disk isn't
added yet.

Maybe it is another warning, care to post the warning log here?


Thanks, 
Ming