Re: [PATCH v6 12/16] mm: list_lru: replace linear array with xarray

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux