Re: [PATCH] nilfs2: fix NULL i_assoc_inode dereference in nilfs_mdt_save_to_shadow_map
Ryusuke Konishi <[email protected]> Wed, 18 Mar 2026 11:10:21 +0900
| Newsgroups | org.kernel.vger.linux-nilfs,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAKFNMo=eqZDh3zEWX2Vyi853Hz8JdUJ7_kAqQbFcJfsS7Ld0Cg@mail.gmail.com> |
On Tue, Mar 17, 2026 at 6:01 PM Deepanshu Kartikey wrote: > > > The DAT inode's btree node cache (i_assoc_inode) is initialized lazily > during btree operations. However, nilfs_mdt_save_to_shadow_map() > assumes i_assoc_inode is already initialized when copying dirty pages > to the shadow map during GC. > > If NILFS_IOCTL_CLEAN_SEGMENTS is called immediately after mount before > any btree operation has occurred on the DAT inode, i_assoc_inode is > NULL leading to a general protection fault. > > Fix this by calling nilfs_attach_btree_node_cache() on the DAT inode > in nilfs_dat_read() at mount time, ensuring i_assoc_inode is always > initialized before any GC operation can use it. > > Reported-by: [email protected] > Closes: https://syzkaller.appspot.com/bug?extid=4b4093b1f24ad789bf37 > Tested-by: [email protected] > Fixes: e897be17a441 ("nilfs2: fix lockdep warnings in page operations for btree nodes") > Signed-off-by: Deepanshu Kartikey <[email protected]> > --- > fs/nilfs2/dat.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/nilfs2/dat.c b/fs/nilfs2/dat.c > index 674380837ab9..888dc1831c86 100644 > --- a/fs/nilfs2/dat.c > +++ b/fs/nilfs2/dat.c > @@ -524,6 +524,9 @@ int nilfs_dat_read(struct super_block *sb, size_t entry_size, > if (err) > goto failed; > > + err = nilfs_attach_btree_node_cache(dat); > + if (err) > + goto failed; > err = nilfs_read_inode_common(dat, raw_inode); > if (err) > goto failed; > -- > 2.43.0 > As I've already answered in a discussion about another patch for the same issue, I'd like to adopt Deepanshu's patch as the fix for this issue, after doing a little more review (mainly for error cases) and testing just to be sure. This fix pre-allocates inodes for the b-tree node cache and is a comprehensive stabilization technique that covers multiple potential cases regarding non-existent b-tree node cache references. Since DAT usually starts using b-tree mapping very quickly, I believe this approach is not overkill and is a practical solution. Thanks, Ryusuke Konishi