linux-kernel - Re: Re: [PATCH v1 1/5] f2fs: Zero f2fs_folio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGsJ_4w8+av0kPrSnGApTcJ9HGV6_Yhc+XeQLgUkAapMvAzEdQ@mail.gmail.com>
Date: Fri, 9 Jan 2026 11:35:37 +1300
From: Barry Song <21cnbao@...il.com>
To: Nanzhe Zhao <nzzhao@....com>
Cc: Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>, 
	linux-f2fs-devel <linux-f2fs-devel@...ts.sourceforge.net>, 
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH v1 1/5] f2fs: Zero f2fs_folio_state on allocation

On Wed, Jan 7, 2026 at 4:45 PM Nanzhe Zhao <nzzhao@....com> wrote:
>
> Hi Barry:
>
> >At 2026-01-06 11:38:49, "Barry Song" <21cnbao@...il.com> wrote:
> >>On Tue, Jan 6, 2026 at 12:12 AM Nanzhe Zhao <nzzhao@....com> 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 <nzzhao@....com>
> >>
> >>
> >>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?

With GFP_NOIO, we will not swap out pages, including anonymous folios.

                if (folio_test_anon(folio) && folio_test_swapbacked(folio)) {
                        if (!folio_test_swapcache(folio)) {
                                if (!(sc->gfp_mask & __GFP_IO))
                                        goto keep_locked;

When using GFP_NOFS, reclaim can still swap out an anon folio,
provided its swap entry is not filesystem-backed
(see folio_swap_flags(folio)).

static bool may_enter_fs(struct folio *folio, gfp_t gfp_mask)
{
        if (gfp_mask & __GFP_FS)
                return true;
        if (!folio_test_swapcache(folio) || !(gfp_mask & __GFP_IO))
                return false;
        /*
         * We can "enter_fs" for swap-cache with only __GFP_IO
         * providing this isn't SWP_FS_OPS.
         * ->flags can be updated non-atomicially (scan_swap_map_slots),
         * but that will never affect SWP_FS_OPS, so the data_race
         * is safe.
         */
        return !data_race(folio_swap_flags(folio) & SWP_FS_OPS);
}

Note that swap may be backed either by a filesystem swapfile or
directly by a block device.

In short, GFP_NOIO is stricter than GFP_NOFS: it disallows any I/O,
even if the I/O does not involve a filesystem, whereas GFP_NOFS
still permits I/O that is not filesystem-related.

>
> 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.)

This can be the case for a swapfile on F2FS. Note that the check is
performed per folio. On a system with both zRAM and a filesystem-
backed swapfile, some folios may be swapped out while others may
not, depending on where their swap slots are allocated.

>
> 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.

In general, GFP_NOIO is used when handling bios or requests.

Thanks
Barry