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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1a779a14.3453.19b968e6f2d.Coremail.nzzhao@126.com>
Date: Wed, 7 Jan 2026 11:44:35 +0800 (CST)
From: "Nanzhe Zhao" <nzzhao@....com>
To: "Barry Song" <21cnbao@...il.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

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?

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