lkml.org 
[lkml]   [2022]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v6 12/16] mm: list_lru: replace linear array with xarray
On Thu, Mar 31, 2022 at 12:25 PM NeilBrown <neilb@suse.de> 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.

\
 
 \ /
  Last update: 2022-03-31 08:17    [W:0.131 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site