From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 22EAF1DE89A for ; Wed, 7 Jan 2026 03:08:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767755333; cv=none; b=eo1sStfde/VfkeqFj9btOOxChTl8JNGDvaDUDcFe+MMvWUnqGsd905lNac2xSGdhokZwl2WN8PsJQLHyOPeooGqnWfSuWTDy2H7tFlVgPzJj8IXCjzTI411GcP96VDMtIJRZpRdl115rbzU8MN3texmSXxqx62/xPfm3Ccvaq+c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767755333; c=relaxed/simple; bh=87dNdUNN2virltNHFfyr21vp2fuJcOmqOPe8cvIurxM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=T2I3kw49GUkc9Spynbgmft8UkudOsoHZOuhj3FCdSpDMehKyldXXOVRBwibMdEN4MDZtfJplHoHNwSYRr6xcmwsaccPzHR0uZnYIOv3aTzWvTqgteiC6WOE9eDJqfD7bjzrT95wyI76kpz+V75nkrGHnnq374PmWf//zv5kh24Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RgVVA47Q; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RgVVA47Q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A2BEC116C6; Wed, 7 Jan 2026 03:08:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767755332; bh=87dNdUNN2virltNHFfyr21vp2fuJcOmqOPe8cvIurxM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RgVVA47QDHiFCrJXDZSY5O6e+vOGCH8CAy4dzWBQpnVW/X212xUQQdvP3MFzGdHm6 T25vB9GG2kOvZVs7eV0ugV0bC5kcEXosdmimwO1rfs3UUMR0lw97JuHOTDYaU3/a2N K6bPi7LLa92m+vHCdFLeGhNFJfx1ui6zpMW2gH3RDcAFCc5ePUAkPAOqGo3aUvznyP Ey2VtOOYfs/4ttQlyUrXInGMxAnjHMRw/zBTUbKi3i18lQOIopW1hQaEBkyQuvdIuB aO/WjED1xT2x1x4mOteH12TjvUYe2qKb3mcKtOEg5UZ3rIeY/OgrioLbf92YSbCp/m cuyLb/UcCIUNA== Date: Wed, 7 Jan 2026 03:08:50 +0000 From: Jaegeuk Kim To: Nanzhe Zhao Cc: Chao Yu , linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 0/5] f2fs: fix large folio read corner cases for immutable files Message-ID: References: <20260105153101.152892-1-nzzhao@126.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260105153101.152892-1-nzzhao@126.com> 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