From nobody Mon Sep 28 18:34:34 2026 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C68330DD10 for ; Tue, 18 Aug 2026 14:55:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787064946; cv=none; b=gUON52Hkvcv4sFwHIdeLMSEZiMu6iETjGmCY0oWDJIIeXMh6+swwY12zNxb0jzdLxDH99gxiAFDf8P+vdk6zFAdCnmB8vXADumNa8KLbq/48r2O4uz0zTpTkLEBCmHbUJrNKxz0NGEVkSFJAjjqYjXxIg3IBvwhLAJsycK+UzWM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787064946; c=relaxed/simple; bh=cBojm8RkVX6FRIrkZj9tO4jHBWALogJ6xQ3/fRKghc0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=LU0K7HzdsXhZI7uXvxnkejbrZaARxEjaAyD774ELCGx349csQexL8hS2wY9yl8mGmGLfsLwM8UJMmfLImrAU95xxfFn3Q5v7hmatuRDQyiavXAzpB/PX38iM8VvwkV0MOgWyiPmdqL6/JoZ8v0qFaTOwrHOuRK2B7+u+HDA8dpY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=UHzr1RHK; arc=none smtp.client-ip=209.85.216.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="UHzr1RHK" Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-381c51fde6bso7633a91.2 for ; Tue, 18 Aug 2026 07:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787064944; x=1787669744; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=YsFaoS644NH2HkD0bh5kmr+46rtAuXi0WRjeGi4FwF4=; b=UHzr1RHKNWo/7uDDbcqtSRB443DT27So1KBIHmYRkfeOdO5g+9n1fObM6ziWvimRFD OtYBxVMJX1BRmbsgV9hRkkKrgKtS/l0plrb+3rIbWCJGy3sDjA9bahxGq2f87KLqwx0T z/4cc7bqgOL/c7jjHGdr5X3xQLAdoYPgPXY6fruoUgOi0IVLOK329fmL30lhQUTNoaTU CMJ88aRhyO8uSx7zlAjl3xjrAVgI/GcFPtLXY5eyxbcKOLo6cnGBHRQMrkds8zoT6y01 37RxMyNig8KB71OQLuDbDreJVkSKaNPtI8mlgKvUqCSZCljzr87SXsuqBC9workKc92d 1DqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787064944; x=1787669744; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=YsFaoS644NH2HkD0bh5kmr+46rtAuXi0WRjeGi4FwF4=; b=Vx5eTDDAqqN4cImj0Gh2tfPuJHc7/mkAfD8vNShi6CEGhifvh5onD8aqS632PiStzo jz3FhrIUgMTNkF/O6EUWDqi+D6FqFVfPUOw+cGd8OvAifIO8gJj8QNnAfxDg+/vSqnFe lt5QHJ08rofw2PgDUWrHVPgnhOg4X52PMeU7LU0/RlhJC5uyPvefJMi/H8dCsxUAecyk DLhPfB11E8/P4UG07NG/IEPgvUsZqrFlY3aPUQo9X2L7bQeHN9F/EPilKz9g8cGvltgg sIW6SY4O4FTNuDWyMH2iMHic8l4RIrEJLZJutnFVOxbPavUbkHvfwIv7mfVh8QKwhAiu 4jdg== X-Forwarded-Encrypted: i=1; AHgh+RowHZKlCaiwlR64GylPcYehLYBwqwTHbi/7hyG7mh0xyluQkfAQSfOJXhPFWaYV1Ync8Pvy35oa8PfFhQ8=@vger.kernel.org X-Gm-Message-State: AOJu0YyZt2R0zJLWcnuC0B3TGZ8hw09lns78nVJGpkRy2jAMjWFM0Oei kdOZfKG29k+arZk9jnYRARg/G9hgHm4Wjjg6L1QRN13EmraNrI2skFZf X-Gm-Gg: AR+sD10aRjJBnyvkLjzmLItGjJPe0Vyqr/9fx7fz3TAV9ThD060IYZdM8GhX7UhtEdX j5g6cJS46F1xfN9/uOb4yjNBgdZMX9cZj6M0hCzikK98Ng7IxSkMzgW6Nq2dTjEXQNzDhlolRMT juDjWB5ZKRvNJMkcIdEpnInjGLjmeBgEYBz4NRXA4orn+JDM1F3Cw7TWobEIfEee672NRLsaWFE d2tuNGyPfuQaZxpHeNj+Lr+iCEmx/Nt581OhIRH2n9ZU0hLhGwfHIKDs1vJ2WYkoBaCxNm3BWMU iyffHCaQ4AaX0bIHuEXb49o21uP5k5a3jJCr2HdTwKWvvjcNEl0q/0pPKyRp3GAnuDTXTzSbTsN pcs6jwWw8Zm2AJXjbYGXndztUq6t0JsU3wg4FzE2JYI2iSGdN/DWPtCWTcAtXzHAbeeJ5QChP/t zKbOBNUBwP8gpAbZQMqESq3hi1zhKQgmiodbglmUQ2BfRPiGso7CFpZF4vpxuqaNDhOpxxTu/Sn xBk4s0xpuk= X-Received: by 2002:a17:90b:17c5:b0:36b:bec8:94c5 with SMTP id 98e67ed59e1d1-3933b874ad6mr34245555a91.10.1787064944280; Tue, 18 Aug 2026 07:55:44 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-39339d00eafsm7363740a91.1.2026.08.18.07.55.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 07:55:43 -0700 (PDT) From: Zhan Xusheng X-Google-Original-From: Zhan Xusheng To: Jaegeuk Kim , Chao Yu Cc: Sunmin Jeong , Sungjong Seo , Yeongjin Gil , Yunji Kang , zhanxusheng@xiaomi.com, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Zhan Xusheng Subject: [PATCH v2] f2fs: fix i_size when pinned fallocate partially fails Date: Tue, 18 Aug 2026 22:55:35 +0800 Message-ID: <20260818145535.449055-1-zhanxusheng@xiaomi.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhan Xusheng From: Zhan Xusheng Commit 4275b59673eb ("f2fs: fix to round down start offset of fallocate for pin file") moved the allocation loop's start down to a section boundary, but the error path still converts @expanded against @pg_start, which holds the unrounded start. @pg_start exists for that conversion: commit 88f2cfc5fa90 ("f2fs: fix to update last i_size if fallocate partially succeeds") added it as an immutable base because map.m_lblk moves every round. Each round now maps exactly sec_blks blocks starting from rounddown(pg_start, sec_blks), so pg_start + expanded overshoots the last allocated block by pg_start % sec_blks, and a partial failure leaves i_size covering a tail that was never allocated. Nothing corrects that afterwards either, since file_dont_truncate() has already cleared FADVISE_TRUNC_BIT. It needs a start offset that is not section aligned plus a fallocate that hits ENOSPC partway, so the error path runs with expanded > 0. On an 80 MiB image with 2 MiB sections: truncate -s 80M img mkfs.f2fs -s 1 -f img mount -o loop img /mnt touch /mnt/pinned f2fs_io pinfile set /mnt/pinned # 2093056 =3D block 511, so pg_start % sec_blks =3D 511 f2fs_io fallocate 0 2093056 536870912 /mnt/pinned stat -c %s /mnt/pinned filefrag -v /mnt/pinned The last extent ends at block 10737 either way. Before, i_size is 46075904, block 11249, so 511 blocks of it were never allocated, and filefrag does not mark the last extent eof. After, i_size is 43982848, block 10738, and eof is back. A kernel from before that commit also shows no overshoot. Keep @pg_start pointing at where allocation actually begins. Fixes: 4275b59673eb ("f2fs: fix to round down start offset of fallocate for= pin file") Cc: stable@vger.kernel.org Signed-off-by: Zhan Xusheng Reviewed-by: Chao Yu --- v1->v2: - Added the reproducer and the before/after numbers to the changelog, as asked by Chao Yu. No code change. v1: https://lore.kernel.org/r/20260817022723.3324123-1-zhanxusheng@xiaomi.c= om fs/f2fs/file.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 4b52c56d71f0..cc0d2b8c4684 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -1919,8 +1919,9 @@ static int f2fs_expand_inode_data(struct inode *inode= , loff_t offset, block_t sec_len; =20 if (map.m_lblk % sec_blks) { - map.m_lblk =3D rounddown(map.m_lblk, sec_blks); - map.m_len =3D pg_end - map.m_lblk; + pg_start =3D rounddown(map.m_lblk, sec_blks); + map.m_lblk =3D pg_start; + map.m_len =3D pg_end - pg_start; if (off_end) map.m_len++; } --=20 2.43.0