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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMZfGtX9pkWYf40RwDALZLKGDc+Dt2UJA7wZFjTagf0AyWyCiw@mail.gmail.com>
Date:   Thu, 31 Mar 2022 14:16:17 +0800
From:   Muchun Song <songmuchun@...edance.com>
To:     NeilBrown <neilb@...e.de>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...nel.org>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Shakeel Butt <shakeelb@...gle.com>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Yang Shi <shy828301@...il.com>, Alex Shi <alexs@...nel.org>,
        Wei Yang <richard.weiyang@...il.com>,
        Dave Chinner <david@...morbit.com>,
        trond.myklebust@...merspace.com, anna.schumaker@...app.com,
        jaegeuk@...nel.org, chao@...nel.org,
        Kari Argillander <kari.argillander@...il.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        linux-nfs@...r.kernel.org, Qi Zheng <zhengqi.arch@...edance.com>,
        Xiongchun duan <duanxiongchun@...edance.com>,
        Fam Zheng <fam.zheng@...edance.com>,
        Muchun Song <smuchun@...il.com>
Subject: Re: [PATCH v6 12/16] mm: list_lru: replace linear array with xarray

On Thu, Mar 31, 2022 at 12:25 PM NeilBrown <neilb@...e.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.