Re: [PATCH] nilfs2: no longer save to shadow map if the num of members is too small

Hi Edward, thank you as always.

On Wed, Mar 18, 2026 at 9:08 AM Edward Adam Davis wrote:
>
> Have you been following the path below? If the argv0.v_nmembs value
> passed from userspace is greater than 0, everything will function normally.
>
> nilfs_ioctl_clean_segments()->
>   nilfs_ioctl_move_blocks()->
>     nilfs_iget_for_gc()->
>       nilfs_init_gcinode()->
>         nilfs_attach_btree_node_cache()
>
> Causing the mount to fail solely because the dat B-tree wasn't initialized
> is an excessive fix.
>
> BR,
> Edward

Are you perhaps confusing the regular inode's GC cache (gc inode) with
the DAT's shadow mapping inode?

Calling nilfs_attach_btree_node_cache() from nilfs_init_gcinode() does
not allocate the b-tree node cache for the DAT inode where the problem
is occurring in nilfs_mdt_save_to_shadow_map().
Therefore, it does not fix the root cause of the issue.

As can be seen from the call trace below, the issue arises when the
i_assoc_inode of the DAT inode (or potentially its shadow mapping
inode) in nilfs_mdt_save_to_shadow_map() is dereferenced.

  RIP: 0010:nilfs_mdt_save_to_shadow_map+0x141/0x1c0 fs/nilfs2/mdt.c:559

Your fix eliminates the reproducibility conditions for the reproducer,
so it might pass the tests, but it doesn't fix the original problem,
does it?

The essential flaw is that it attempts to copy dirty pages from the
b-tree node cache to the shadow mapping, even though the DAT might not
have a btree node cache while remaining in direct mapping mode.

As I mentioned earlier, DAT usually grows quickly and switches to
btree mapping, so I don't think it's excessive to pre-allocate a btree
node cache as Deepanshu proposed.

Regards,
Ryusuke Konishi