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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aV3OQu3ea5-DgzmT@google.com>
Date: Wed, 7 Jan 2026 03:08:50 +0000
From: Jaegeuk Kim <jaegeuk@...nel.org>
To: Nanzhe Zhao <nzzhao@....com>
Cc: Chao Yu <chao@...nel.org>, linux-f2fs-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 0/5] f2fs: fix large folio read corner cases for
 immutable files

Hi Nanzhe,

fyi - I applied the beginning two patches first.

Thanks,

On 01/05, Nanzhe Zhao wrote:
> When reading immutable, non-compressed files with large folios enabled,
> I was able to reproduce readahead hangs while reading sparse files with
> holes and heavily fragmented files. The problems were caused by a few
> corner cases in the large-folio read loop:
> 
>   - f2fs_folio_state could be observed with uninitialized field
>     read_pages_pending
>   - subpage accounting could become inconsistent with BIO completion,
>     leading to folios being prematurely unlocked/marked uptodate.
>   - NULL_ADDR/NEW_ADDR blocks can carry F2FS_MAP_MAPPED, causing the
>     large-folio read path to treat hole blocks as mapped and to account
>     them in read_pages_pending.
>   - in readahead, a folio that never had any subpage queued to a BIO
>     would not be seen by f2fs_finish_read_bio(), leaving it locked.
>   - the zeroing path did not advance index/offset before continuing.
> 
> This patch series fixes the above issues in f2fs_read_data_large_folio()
> introduced by commit 05e65c14ea59 ("f2fs: support large folio for
> immutable non-compressed case").
> 
> Testing
> -------
> 
> All patches pass scripts/checkpatch.pl.
> 
> I tested the basic large-folio immutable read case described in the
> original thread (create a large file, set immutable, drop caches to
> reload the inode, then read it), and additionally verified:
> 
>   - sparse file
>   - heavily fragmented file
> 
> In all cases, reads completed without hangs and data was verified against
> the expected contents.
> 
> Nanzhe Zhao (5):
>   f2fs: Zero f2fs_folio_state on allocation
>   f2fs: Accounting large folio subpages before bio submission
>   f2fs: add f2fs_block_needs_zeroing() to handle hole blocks
>   f2fs: add 'folio_in_bio' to handle readahead folios with no BIO
>     submission
>   f2fs: advance index and offset after zeroing in large folio read
> 
>  fs/f2fs/data.c | 54 +++++++++++++++++++++++++++++++++-----------------
>  1 file changed, 36 insertions(+), 18 deletions(-)
> 
> 
> base-commit: 48b5439e04ddf4508ecaf588219012dc81d947c0
> --
> 2.34.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ