Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220228122126.37293-1-songmuchun@bytedance.com>
 <20220228122126.37293-13-songmuchun@bytedance.com> <164869718565.25542.15818719940772238394@noble.neil.brown.name>
 <CAMZfGtUSA9f3k9jF5U-y+NVt8cpmB9_mk1F9-vmm4JOuWFF_Bw@mail.gmail.com> <164870069595.25542.17292003658915487357@noble.neil.brown.name>
In-Reply-To: <164870069595.25542.17292003658915487357@noble.neil.brown.name>
From:   Muchun Song <songmuchun@bytedance.com>
Date:   Thu, 31 Mar 2022 14:16:17 +0800
Message-ID: <CAMZfGtX9pkWYf40RwDALZLKGDc+Dt2UJA7wZFjTagf0AyWyCiw@mail.gmail.com>
Subject: Re: [PATCH v6 12/16] mm: list_lru: replace linear array with xarray
To:     NeilBrown <neilb@suse.de>,
        Andrew Morton <akpm@linux-foundation.org>
Cc:     Matthew Wilcox <willy@infradead.org>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Michal Hocko <mhocko@kernel.org>,
        Vladimir Davydov <vdavydov.dev@gmail.com>,
        Shakeel Butt <shakeelb@google.com>,
        Roman Gushchin <roman.gushchin@linux.dev>,
        Yang Shi <shy828301@gmail.com>, Alex Shi <alexs@kernel.org>,
        Wei Yang <richard.weiyang@gmail.com>,
        Dave Chinner <david@fromorbit.com>,
        trond.myklebust@hammerspace.com, anna.schumaker@netapp.com,
        jaegeuk@kernel.org, chao@kernel.org,
        Kari Argillander <kari.argillander@gmail.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux Memory Management List <linux-mm@kvack.org>,
        linux-nfs@vger.kernel.org, Qi Zheng <zhengqi.arch@bytedance.com>,
        Xiongchun duan <duanxiongchun@bytedance.com>,
        Fam Zheng <fam.zheng@bytedance.com>,
        Muchun Song <smuchun@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.