Re: [PATCH 00/24] xfs: rework inode flushing to make inode reclaim fully asynchronous

Dave Chinner
2020-05-23T21:22:55Z

On Sat, May 23, 2020 at 09:18:33AM -0700, Darrick J. Wong wrote:
> On Fri, May 22, 2020 at 02:04:01PM +1000, Dave Chinner wrote:
> >
> > FWIW, I forgot to put it in the original description - the series
> > can be pulled from my git tree here:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git xfs-async-inode-reclaim
>
> Hmm, so I tried this out with quotas enabled and hit this in xfs/438:

Yeah, I found another bug about 2 hours after I send this - the
iodone error ->li_error callouts are not handled correctly, but I
haven't seen this one.

>
> MKFS_OPTIONS="-m reflink=1,rmapbt=1 -i sparse=1 /dev/sdf
> MOUNT_OPTIONS="-o usrquota,grpquota,prjquota"
>
> BUG: kernel NULL pointer dereference, address: 0000000000000020
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: 0000 [#1] PREEMPT SMP
> CPU: 3 PID: 824887 Comm: xfsaild/dm-0 Tainted: G W 5.7.0-rc4-djw #rc4
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1 04/01/2014
> RIP: 0010:do_raw_spin_trylock+0x5/0x40
> Code: 64 de 81 48 89 ef e8 ba fe ff ff eb 8b 89 c6 48 89 ef e8 de dc ff ff 66 90 eb 8b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <8b> 07 85 c0 75 28 ba 01 00 00 00 f0 0f b1 17 75 1d 65 8b 05 83 d8
> RSP: 0018:ffffc90000afbdc0 EFLAGS: 00010086
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: ffff888070ee0000 RSI: 0000000000000000 RDI: 0000000000000020
> RBP: 0000000000000020 R08: 0000000000000001 R09: 0000000000000001
> R10: 0000000000000000 R11: ffffc90000afbc3d R12: 0000000000000038
> R13: 0000000000000202 R14: 0000000000000003 R15: ffff88800688a600
> FS: 0000000000000000(0000) GS:ffff88807e000000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000020 CR3: 000000003bba2001 CR4: 00000000001606a0
> Call Trace:
> _raw_spin_lock_irqsave+0x47/0x80
> ? down_trylock+0xf/0x30
> down_trylock+0xf/0x30
> xfs_buf_trylock+0x1a/0x1f0 [xfs]
> xfsaild+0xb69/0x1320 [xfs]
> kthread+0x130/0x170

Where is xfsaild calling xfs_buf_trylock directly?

Oh, resubmission of failed inode and dquot items, which may well be
the same problem as I mentioned above. I'll try to reproduce on
Monday...

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com