Re: [PATCH 2/2] fserror: fix lockdep complaint when igrabbing inode

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Feb 19, 2026 at 09:11:28AM +0100, Christian Brauner wrote:
> On Wed, Feb 18, 2026 at 10:15:46PM -0800, Darrick J. Wong wrote:
> > On Wed, Feb 18, 2026 at 10:09:37PM -0800, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <djwong@kernel.org>
> > > 
> > > Christoph Hellwig reported a lockdep splat in generic/108:
> > > 
> > >  ================================
> > >  WARNING: inconsistent lock state
> > >  6.19.0+ #4827 Tainted: G                 N
> > >  --------------------------------
> > >  inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> > >  swapper/1/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
> > >  ffff88811ed1b140 (&sb->s_type->i_lock_key#33){?.+.}-{3:3}, at: igrab+0x1a/0xb0
> > >  {HARDIRQ-ON-W} state was registered at:
> > >    lock_acquire+0xca/0x2c0
> > >    _raw_spin_lock+0x2e/0x40
> > >    unlock_new_inode+0x2c/0xc0
> > >    xfs_iget+0xcf4/0x1080
> > >    xfs_trans_metafile_iget+0x3d/0x100
> > >    xfs_metafile_iget+0x2b/0x50
> > >    xfs_mount_setup_metadir+0x20/0x60
> > >    xfs_mountfs+0x457/0xa60
> > >    xfs_fs_fill_super+0x6b3/0xa90
> > >    get_tree_bdev_flags+0x13c/0x1e0
> > >    vfs_get_tree+0x27/0xe0
> > >    vfs_cmd_create+0x54/0xe0
> > >    __do_sys_fsconfig+0x309/0x620
> > >    do_syscall_64+0x8b/0xf80
> > >    entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > >  irq event stamp: 139080
> > >  hardirqs last  enabled at (139079): [<ffffffff813a923c>] do_idle+0x1ec/0x270
> > >  hardirqs last disabled at (139080): [<ffffffff828a8d09>] common_interrupt+0x19/0xe0
> > >  softirqs last  enabled at (139032): [<ffffffff8134a853>] __irq_exit_rcu+0xc3/0x120
> > >  softirqs last disabled at (139025): [<ffffffff8134a853>] __irq_exit_rcu+0xc3/0x120
> > > 
> > >  other info that might help us debug this:
> > >   Possible unsafe locking scenario:
> > > 
> > >         CPU0
> > >         ----
> > >    lock(&sb->s_type->i_lock_key#33);
> > >    <Interrupt>
> > >      lock(&sb->s_type->i_lock_key#33);
> > > 
> > >   *** DEADLOCK ***
> > > 
> > >  1 lock held by swapper/1/0:
> > >   #0: ffff8881052c81a0 (&vblk->vqs[i].lock){-.-.}-{3:3}, at: virtblk_done+0x4b/0x110
> > > 
> > >  stack backtrace:
> > >  CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G                 N  6.19.0+ #4827 PREEMPT(full)
> > >  Tainted: [N]=TEST
> > >  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
> > >  Call Trace:
> > >   <IRQ>
> > >   dump_stack_lvl+0x5b/0x80
> > >   print_usage_bug.part.0+0x22c/0x2c0
> > >   mark_lock+0xa6f/0xe90
> > >   __lock_acquire+0x10b6/0x25e0
> > >   lock_acquire+0xca/0x2c0
> > >   _raw_spin_lock+0x2e/0x40
> > >   igrab+0x1a/0xb0
> > >   fserror_report+0x135/0x260
> > >   iomap_finish_ioend_buffered+0x170/0x210
> > >   clone_endio+0x8f/0x1c0
> > >   blk_update_request+0x1e4/0x4d0
> > >   blk_mq_end_request+0x1b/0x100
> > >   virtblk_done+0x6f/0x110
> > >   vring_interrupt+0x59/0x80
> > >   __handle_irq_event_percpu+0x8a/0x2e0
> > >   handle_irq_event+0x33/0x70
> > >   handle_edge_irq+0xdd/0x1e0
> > >   __common_interrupt+0x6f/0x180
> > >   common_interrupt+0xb7/0xe0
> > >   </IRQ>
> > > 
> > > It looks like the concern here is that inode::i_lock is sometimes taken
> > > in IRQ context, and sometimes it is held when going to IRQ context,
> > > though it's a little difficult to tell since I think this is a kernel
> > > from after the actual 6.19 release but before 7.0-rc1.
> > > 
> > > Either way, we don't need to take i_lock, because filesystems should
> > > not report files to fserror if they're about to be freed or have not
> > > yet been exposed to other threads, because the resulting fsnotify report
> > > will be meaningless.
> > > 
> > > Therefore, bump inode::i_count directly and clarify the preconditions on
> > > the inode being passed in.
> > 
> > ...and now I realize that I got so hung up on email cc list composition
> 
> I honestly just use b4 prep --auto-to-cc

So do I, but I ^R'd and got one with linux-xfs by mistake.  Unless
there's some magic "read MAINTAINERS functionality" that I haven't
discovered yet?  I haven't updated in quite a while.

> > that I neglected to notice that I forgot to update the commit message
> > to say:
> > 
> > "Therefore, add the ioend to a queue and get an async worker to chug
> > through the error events from process context with no filesystem locks
> > already held."
> > 
> > Let's hope I got the paperwork right this time, all this friction to
> > amend minor mistakes are why I don't want to be here anymore. <grumble>
> 
> You know, I can just add that for you when applying. :)

I prefer to resend the whole series with /all/ the correct tags and
messages so it actually gets recorded here accurately.

Also, would you mind picking up the first patch for 7.0-rc2 so that the
old fsnotify helper is gone for good?

--D