On Thu, Mar 31, 2022 at 12:25 PM NeilBrown <neilb@xxxxxxx> wrote: > > On Thu, 31 Mar 2022, Muchun Song wrote: > > > > If the above fix cannot fix your issue, would you mind providing > > the .config and stack trace? > > The kernel I'm using is > 74164d284b2909de0ba13518cc063e9ea9334749 > plus one patch in fs/namei.c > So it does include the commit you mentioned. > > Config is below > > I run > ./check -nfs generic/037 > in xfstests, and crash is quick. > > Stack trace is > > [ 121.557601] BUG: kernel NULL pointer dereference, address: 0000000000000008 > [ 121.558003] #PF: supervisor read access in kernel mode > [ 121.558299] #PF: error_code(0x0000) - not-present page > [ 121.558598] PGD 0 P4D 0 > [ 121.558750] Oops: 0000 [#1] PREEMPT SMP > [ 121.558978] CPU: 2 PID: 1116 Comm: setfattr Not tainted 5.17.0-dev #455 > [ 121.559360] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 > [ 121.560009] RIP: 0010:list_lru_add+0x58/0xae > [ 121.560267] Code: 00 48 8d 58 48 74 23 48 89 ef e8 93 08 03 00 49 89 c5 48 85 c0 74 13 8b 90 40 0e 00 00 31 f6 4c 89 e7 e8 66 fb ff ff 48 3 > [ 121.561353] RSP: 0018:ffffc900016dfbd0 EFLAGS: 00010246 > [ 121.561668] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000094fd1aeb > [ 121.562076] RDX: ffff888007768be8 RSI: ffffffff826b4914 RDI: ffffffff82745064 > [ 121.562484] RBP: ffff8880097b3888 R08: ffffffffffffffff R09: ffff888007768b40 > [ 121.562890] R10: ffffc900016dfa98 R11: 0000000000008f0c R12: ffffffff8482e7a0 > [ 121.563296] R13: ffff888007766000 R14: ffff888005e72300 R15: 0000000000000000 > [ 121.563702] FS: 00007f558ef08580(0000) GS:ffff88801f200000(0000) knlGS:0000000000000000 > [ 121.564166] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 121.564499] CR2: 0000000000000008 CR3: 00000000084c4000 CR4: 00000000000006e0 > [ 121.564905] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 121.565314] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > [ 121.565719] Call Trace: > [ 121.565860] <TASK> > [ 121.565985] nfs4_xattr_get_cache+0x131/0x169 > [ 121.566239] nfs4_xattr_cache_add+0x47/0x15a > [ 121.566485] nfs4_xattr_set_nfs4_user+0xcb/0xef > [ 121.566748] __vfs_setxattr+0x66/0x72 > [ 121.566961] __vfs_setxattr_noperm+0x6e/0xf5 > [ 121.567211] vfs_setxattr+0xa7/0x12a > [ 121.567419] setxattr+0x115/0x14d > [ 121.567612] ? check_chain_key+0xde/0x11f > [ 121.567846] path_setxattr+0x78/0xcf > [ 121.568053] __x64_sys_setxattr+0x22/0x25 > [ 121.568287] do_syscall_64+0x6d/0x80 > [ 121.568497] entry_SYSCALL_64_after_hwframe+0x44/0xae > Thanks for your report. I knew the reason. It is because the following patch in this series was missed upstream. Could you help me test if it works properly? [v6,06/16] nfs42: use a specific kmem_cache to allocate nfs4_xattr_entry Hi Andrew, Would you mind picking it up? Thanks.
