From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>

Our v6.18 based Android system is continuely suffering livelock and bad
page stat as shown in[1] which related to broken xarray slot status. By
investigating big folio operations within f2fs, we find below races and
fix it by get the nr_pages before drop the refcount and folio_lock.

f2fs_get_read_data_folio() calls f2fs_folio_put() before
folio_nr_pages() when invalidating a large folio from the page cache.
That unlocks the folio and drops the caller reference, leaving a window
where a concurrent truncate or folio split can shrink the compound folio
or free it before the invalidate range is computed. An undersized range
then leaves split sub-folios in mapping->i_pages, which can later
interact badly with truncate and reclaim (stale xarray entries and bad
page state when folio->mapping no longer matches the mapping being
truncated).

[1]
PID: 2594     TASK: ffffff8169b81580  CPU: 7    COMMAND: "Thread-3"
 #0 [ffffffc08ef2b8a0] xas_load at ffffffe52d1f42a4
 #1 [ffffffc08ef2b900] find_get_entries at ffffffe52c185798
 #2 [ffffffc08ef2bb60] truncate_inode_pages_range at ffffffe52c19e83c
 #3 [ffffffc08ef2bbc0] truncate_inode_pages_final at ffffffe52c19ec2c
 #4 [ffffffc08ef2bc20] f2fs_evict_inode at ffffffe52c4c8400
 #5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4
 #6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4
 #7 [ffffffc08ef2bd30] dentry_unlink_inode at ffffffe52c2d7204
 #8 [ffffffc08ef2bd50] __dentry_kill at ffffffe52c2d3dcc
 #9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c
 #10 [ffffffc08ef2bda0] __fput at ffffffe52c2b0a7c
 #11 [ffffffc08ef2bde0] ____fput at ffffffe52c2b1034
 #12 [ffffffc08ef2bdf0] task_work_run at ffffffe52beea200
 #13 [ffffffc08ef2be20] exit_to_user_mode_loop at ffffffe52bfbc17c
 #14 [ffffffc08ef2be80] el0_svc at ffffffe52d1f8e54
 #15 [ffffffc08ef2beb0] el0t_64_sync_handler at ffffffe52d1f8d10

Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
---
 fs/f2fs/data.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 8d4f1e75dee3..8a26f2d93c17 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1281,10 +1281,11 @@ struct folio *f2fs_get_read_data_folio(struct inode *inode, pgoff_t index,
 
 	if (folio_test_large(folio)) {
 		pgoff_t folio_index = mapping_align_index(mapping, index);
+		unsigned long nr_pages = folio_nr_pages(folio);
 
 		f2fs_folio_put(folio, true);
 		invalidate_inode_pages2_range(mapping, folio_index,
-				folio_index + folio_nr_pages(folio) - 1);
+				folio_index + nr_pages - 1);
 		f2fs_schedule_timeout(DEFAULT_SCHEDULE_TIMEOUT);
 		goto retry;
 	}
-- 
2.25.1

On 7/13/26 19:19, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> 
> Our v6.18 based Android system is continuely suffering livelock and bad
> page stat as shown in[1] which related to broken xarray slot status. By
> investigating big folio operations within f2fs, we find below races and
> fix it by get the nr_pages before drop the refcount and folio_lock.
> 
> f2fs_get_read_data_folio() calls f2fs_folio_put() before
> folio_nr_pages() when invalidating a large folio from the page cache.
> That unlocks the folio and drops the caller reference, leaving a window
> where a concurrent truncate or folio split can shrink the compound folio
> or free it before the invalidate range is computed. An undersized range
> then leaves split sub-folios in mapping->i_pages, which can later
> interact badly with truncate and reclaim (stale xarray entries and bad
> page state when folio->mapping no longer matches the mapping being
> truncated).
> 
> [1]
> PID: 2594     TASK: ffffff8169b81580  CPU: 7    COMMAND: "Thread-3"
>   #0 [ffffffc08ef2b8a0] xas_load at ffffffe52d1f42a4
>   #1 [ffffffc08ef2b900] find_get_entries at ffffffe52c185798
>   #2 [ffffffc08ef2bb60] truncate_inode_pages_range at ffffffe52c19e83c
>   #3 [ffffffc08ef2bbc0] truncate_inode_pages_final at ffffffe52c19ec2c
>   #4 [ffffffc08ef2bc20] f2fs_evict_inode at ffffffe52c4c8400
>   #5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4
>   #6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4
>   #7 [ffffffc08ef2bd30] dentry_unlink_inode at ffffffe52c2d7204
>   #8 [ffffffc08ef2bd50] __dentry_kill at ffffffe52c2d3dcc
>   #9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c
>   #10 [ffffffc08ef2bda0] __fput at ffffffe52c2b0a7c
>   #11 [ffffffc08ef2bde0] ____fput at ffffffe52c2b1034
>   #12 [ffffffc08ef2bdf0] task_work_run at ffffffe52beea200
>   #13 [ffffffc08ef2be20] exit_to_user_mode_loop at ffffffe52bfbc17c
>   #14 [ffffffc08ef2be80] el0_svc at ffffffe52d1f8e54
>   #15 [ffffffc08ef2beb0] el0t_64_sync_handler at ffffffe52d1f8d10
> 

Need fixes and Cc stable line.

> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>

Anyway, the code part looks good.

Reviewed-by: Chao Yu <chao@kernel.org>

Thanks,