Hi Barry: >At 2026-01-06 11:38:49, "Barry Song" <[email protected]> wrote: >>On Tue, Jan 6, 2026 at 12:12 AM Nanzhe Zhao <[email protected]> wrote: >>> >>> f2fs_folio_state is attached to folio->private and is expected to start >>> with read_pages_pending == 0. However, the structure was allocated from >>> ffs_entry_slab without being fully initialized, which can leave >>> read_pages_pending with stale values. >>> >>> Allocate the object with __GFP_ZERO so all fields are reliably zeroed at >>> creation time. >>> >>> Signed-off-by: Nanzhe Zhao <[email protected]> >> >> >>We already have GFP_F2FS_ZERO, but it includes GFP_IO. Should we >>introduce another variant, such as GFP_F2FS_NOIO_ZERO (or similar)? >>Overall, LGTM. >>
I'm still not fully understand about the exact semantics of GFP_NOIO vs GFP_NOFS. I did a bit of digging and, in the current buffered read / readahead context, it seems like there may be no meaningful difference for the purpose of avoiding direct-reclaim recursion deadlocks? My current (possibly incomplete) understanding is that in may_enter_fs(), GFP_NOIO only changes behavior for swapcache folios, rather than file-backed folios that are currently in the read IO path,and the swap writeback path won't recurse back into f2fs's own writeback function anyway. (On phones there usually isn't a swap partition; for zram I guess swap writeback is effectively writing to RAM via the zram block device ? Sorry for not being very familiar with the details there.) I noticed iomap's ifs_alloc uses GFP_NOFS | __GFP_NOFAIL. So if GFP_NOFS is acceptable here, we could simply use GFP_F2FS_ZERO and avoid introducing a new GFP_F2FS_NOIO_ZERO variant? Just curious.I will vote for GFP_NOIO from semantic clarity perspective here. Thanks, Nanzhe _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
