Re: [f2fs-dev] [PATCH 3/4] f2fs: fix fiemap boundary handling when read extent cache is incomplete

[Jaegeuk Kim via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>]

On 02/27, Jaegeuk Kim via Linux-f2fs-devel wrote:
> On 02/27, Yongpeng Yang wrote:
> > On 2/24/26 12:38, Jaegeuk Kim via Linux-f2fs-devel wrote:
> > > On 02/03, Yongpeng Yang wrote:
> > >> From: Yongpeng Yang <yangyongpeng@xiaomi.com>
> > >>
> > >> f2fs_fiemap() calls f2fs_map_blocks() to obtain the block mapping a
> > >> file, and then merges contiguous mappings into extents. If the mapping
> > >> is found in the read extent cache, node blocks do not need to be read.
> > >> However, in the following scenario, a contiguous extent can be split
> > >> into two extents:
> > >>
> > >> root@vm:/mnt/f2fs# dd if=/dev/zero of=data.4M bs=1M count=4 && sync
> > >> root@vm:/mnt/f2fs# dd if=/dev/zero of=data.4M bs=1M count=2 seek=2 conv=notrunc && sync
> > >> root@vm:/mnt/f2fs# echo 3 > /proc/sys/vm/drop_caches # drop 2M~4M extent cache
> > >> root@vm:/mnt/f2fs# dd if=/dev/zero of=data.4M bs=1M count=2 seek=0 conv=notrunc && sync
> > >> root@vm:/mnt/f2fs# f2fs_io fiemap 0 1024 data.4M
> > >> Fiemap: offset = 0 len = 1024
> > >> logical addr.    physical addr.   length           flags
> > >> 0	0000000000000000 0000000006400000 0000000000200000 00001000
> > >> 1	0000000000200000 0000000006600000 0000000000200000 00001001
> > >>
> > >> Although the physical addresses of the ranges 0～2MB and 2M～4MB are
> > >> contiguous, the mapping for the 2M～4MB range is not present in memory.
> > >> When the physical addresses for the 0～2MB range are updated, no merge
> > >> happens because the adjacent mapping is missing from the in-memory
> > >> cache. As a result, fiemap reports two separate extents instead of a
> > >> single contiguous one.
> > >>
> > >> The root cause is that the read extent cache does not guarantee that all
> > >> blocks of an extent are present in memory. Therefore, when the extent
> > >> length returned by f2fs_map_blocks_cached() is smaller than maxblocks,
> > >> the remaining mappings are retrieved via f2fs_get_dnode_of_data() to
> > >> ensure correct fiemap extent boundary handling.
> > >>
> > >> Fixes: cd8fc5226bef ("f2fs: remove the create argument to f2fs_map_blocks")
> > >> Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com>
> > >> ---
> > >>  fs/f2fs/data.c | 14 ++++++++++++--
> > >>  1 file changed, 12 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > >> index 42f15fd9c68e..eedadccf86bb 100644
> > >> --- a/fs/f2fs/data.c
> > >> +++ b/fs/f2fs/data.c
> > >> @@ -1623,8 +1623,18 @@ int f2fs_map_blocks(struct inode *inode, struct f2fs_map_blocks *map, int flag)
> > >>  	lfs_dio_write = (flag == F2FS_GET_BLOCK_DIO && f2fs_lfs_mode(sbi) &&
> > >>  				map->m_may_create);
> > >>  
> > >> -	if (!map->m_may_create && f2fs_map_blocks_cached(inode, map, flag))
> > >> -		goto out;
> > >> +	if (!map->m_may_create) {
> > >> +		if (f2fs_map_blocks_cached(inode, map, flag)) {
> > >> +			if (map->m_len == maxblocks)
> > >> +				goto out;
> > >> +			else {
> > >> +				pgofs =	(pgoff_t)map->m_lblk + map->m_len;
> > >> +				end = map->m_lblk + maxblocks;
> > >> +				ofs = map->m_len;
> > >> +				goto next_dnode;
> > >> +			}
> > >> +		}
> > >> +	}
> > > 
> > > This patch makes a system panic.
> > 
> > I have done some testing and only observed the panic in the
> > f2fs_write_end_io() path. Syzbot has also reported it:
> > https://syzkaller.appspot.com/bug?extid=6e4cb1cac5efc96ea0ca
> > My proposed fix is here:
> > https://lore.kernel.org/all/20260227073052.3940958-2-monty_pavel@sina.com/
> > 
> > Is this the same issue?
> 
> Yeah, I think so.

Actually, not.

[315868.068811] BUG: kernel NULL pointer dereference, address: 0000000000000008
[315868.074623] RIP: 0010:f2fs_map_blocks+0xb70/0x1480 [f2fs]
[315868.201394] Call Trace:
[315868.202689]  <TASK>
[315868.203809]  ? xa_load+0x6c/0xa0
[315868.205431]  f2fs_mpage_readpages+0x22b/0xf80 [f2fs]
[315868.208902]  ? get_page_from_freelist+0x3ff/0x1790
[315868.211374]  ? debug_smp_processor_id+0x17/0x20
[315868.213627]  f2fs_readahead+0xbc/0x110 [f2fs]
[315868.215809]  read_pages+0x60/0x200
[315868.217478]  page_cache_ra_unbounded+0x187/0x260
[315868.220271]  do_page_cache_ra.isra.0+0x62/0x80
[315868.222507]  page_cache_sync_ra+0x69/0x250
[315868.224491]  filemap_get_pages+0x14e/0x740
[315868.226555]  filemap_read+0xfe/0x450
[315868.228488]  ? debug_smp_processor_id+0x17/0x20
[315868.232896]  ? fpregs_assert_state_consistent+0x38/0x60
[315868.235421]  ? fscrypt_dio_supported+0x37/0xa0
[315868.238587]  ? f2fs_force_buffered_io+0x24/0xd0 [f2fs]
[315868.241819]  f2fs_file_read_iter+0x244/0x470 [f2fs]
[315868.246198]  ? f2fs_llseek+0x17c/0x6f0 [f2fs]
[315868.248666]  vfs_read+0x258/0x350
[315868.251489]  ksys_read+0x69/0xe0
[315868.253304]  __x64_sys_read+0x19/0x20
[315868.255961]  x64_sys_call+0x2000/0x2120
[315868.259178]  do_syscall_64+0xd3/0x760
[315868.260930]  ? debug_smp_processor_id+0x17/0x20
[315868.264900]  ? fpregs_assert_state_consistent+0x38/0x60
[315868.268329]  ? do_syscall_64+0x10c/0x760
[315868.273216]  ? kmem_cache_free+0x14a/0x350
[315868.276156]  ? _raw_spin_unlock+0x19/0x40
[315868.278147]  ? __fput+0x199/0x2b0
[315868.279873]  ? fput_close_sync+0x3f/0xc0
[315868.281756]  ? debug_smp_processor_id+0x17/0x20
[315868.285602]  ? fpregs_assert_state_consistent+0x38/0x60
[315868.288218]  ? do_syscall_64+0x10c/0x760
[315868.291295]  ? debug_smp_processor_id+0x17/0x20
[315868.293514]  ? fpregs_assert_state_consistent+0x38/0x60
[315868.295924]  ? do_syscall_64+0x3cf/0x760
[315868.298689]  ? clear_bhb_loop+0x30/0x80
[315868.300504]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[315868.302812] RIP: 0033:0x7f50ed51a7a1

> 
> > 
> > Thanks
> > Yongpeng,
> > 
> > > 
> > >>  
> > >>  	map->m_bdev = inode->i_sb->s_bdev;
> > >>  	map->m_multidev_dio =
> > >> -- 
> > >> 2.43.0
> > > 
> > > 
> > > _______________________________________________
> > > Linux-f2fs-devel mailing list
> > > Linux-f2fs-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel