From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.126.com (m16.mail.126.com [220.197.31.7]) (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 BA75C1D8E10 for ; Mon, 5 Jan 2026 15:31:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767627107; cv=none; b=n6I15Kdk1wJJRGAy005ImazadMIWhyrXKOu2Xw7+gC1iRqarSmW3R13eVYj2drLAZnpC9nbcKvtCOX74oHySlBhGiNehiXIJgVfgvAOSPNiQmmMrybmGfqYs6oLpFF17THri96FKHPGpzmMWRYldO2rlau+5h/Ds5S1zZxAWcz0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767627107; c=relaxed/simple; bh=1bXN1aF6Nw/StwdZfv20eGFnLXtqUvfshuWF6B4demo=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=TfmsZMtnZHGGtMbbmLKO1sd29wZTUrroSXkzCEa+q6+dlq/rwO7dHB/+YaYBjckwsvFm67ru9S31/O5snQQ1EbUdR/kK1S27MkT93dlx/rTX8SS/Nv1xVrgVPwm7B3dxk5gskE4qsXh9WBZlS7/zhly5gZUwsYgRKDiBpjG7T0k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com; spf=pass smtp.mailfrom=126.com; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b=prNtQjOW; arc=none smtp.client-ip=220.197.31.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=126.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b="prNtQjOW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=MO tAEewhickz7rXgpIAHT8h7e5O32lYJDRxNeHUkyM8=; b=prNtQjOWfWmQ6W8ee/ WIPu7I2Y3NqdqhiyYiYrwSlJjzNupnDykuZN9qeCJxq/75FKRlDHi+92sCRzTsJE xYBxfzozpZHUw9k2QZjq9QrVjJEnrIaj2f6eYBmc6KO3tzySDmbxF00wOJoTtSjX B0ylwOcbH2d9MbcDYvYgSrG5o= Received: from YLLaptop.. (unknown []) by gzga-smtp-mtada-g0-1 (Coremail) with SMTP id _____wD3t6092Vtp4nHABA--.665S2; Mon, 05 Jan 2026 23:31:10 +0800 (CST) From: Nanzhe Zhao To: Kim Jaegeuk Cc: Chao Yu , linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Nanzhe Zhao Subject: [PATCH v1 0/5] f2fs: fix large folio read corner cases for immutable files Date: Mon, 5 Jan 2026 23:30:56 +0800 Message-Id: <20260105153101.152892-1-nzzhao@126.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wD3t6092Vtp4nHABA--.665S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7KF48Jw1rCFyfGFWDtw15CFg_yoW8ZrW5pa y3GrZ8JF1rGF4S9ayftr1jgr4fJ3y8CFs8GFWxKry7A3W5CFs5WrW8tw1SyFyUCrW3GF4x Zr1j9a47uFyjyFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zi6VbkUUUUU= X-CM-SenderInfo: xq22xtbr6rjloofrz/xtbBsB62hmlb2T5HcwAA3- 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