From nobody Fri Oct 2 04:27:58 2026 Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) (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 D7FA641F7C1 for ; Wed, 5 Aug 2026 11:39:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785929968; cv=none; b=OvLPgj2en0FMzSkrxNvn/pEqa6wXfRTRAE6F0H+/CWVAUjfj+rH2j97A5BwevBXKUTCoJ0WBvr9Kod/Rq4LfRMhFI8XM9k+BWVGQcMbGvVMTRye5oEfQ0OAsysSdGx8e5IvmMDEAw2mw/QTv6TttaTeBKUp7Qdp0ZEP0LAHASE4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785929968; c=relaxed/simple; bh=iAmUHHQzaz4f9Rg6y4wTz9QKPgpQfSPXphBN6MdnwQg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cvOAeSR7rxkL1AuPj3Qo47hKXSK2Uc9c64vT7qXF4JLJhNvb8vipUAwQybX2bkaFERlWD0Kp+euIYOEJZKHm9/RmN5iq000SM15RjkXvd7YIq2EYBZO1Ig95lMDpp07mn0AWXZQb1ckT88KT6oDoOJyoZWUj1yB+pHxnlSleIuA= 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=fBUOcS7Q; arc=none smtp.client-ip=209.85.215.179 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="fBUOcS7Q" Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-ca766c1c9ccso634060a12.0 for ; Wed, 05 Aug 2026 04:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785929966; x=1786534766; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=cWKwxfj+Ulmx669+xXO9b93Zs1csGNYfgoV9iYgU+M8=; b=fBUOcS7QGurlf9Vnc4x6sAfVbAuZfaSJG4VHCVNOVFqqiD27/9FIYC/aif0wt5CjMn x23CXRbXmOYGBYciMN8jGY28rPkNoDOqX1Pf+eR3AcEfO1TRyzu8+SKLjMITPGzP+YW7 WE/rP+VwgWcrPRD8BrLbxtsCas/U0IT81lWiqPOM8gpM85PT45ljoZXu4aYerofKIWyd UgioUGDzsm3M7xEZd4cHv62SLRIOw1Bxvb8RmEMQmI2zLxf6mvXwIaOz/BE/dVxgPaRi 2ffaJHCUl3jnxdSfI+OrqYBhw804lRJx+zZXP0hpO7DEZTJvwxYDzmapBE30xUw7jqdi n1uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785929966; x=1786534766; h=content-transfer-encoding:mime-version:references:in-reply-to :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=cWKwxfj+Ulmx669+xXO9b93Zs1csGNYfgoV9iYgU+M8=; b=JtkUTCU5BmXcHfqFMOzCGiViy02mcIaIwm893W36Xt9CFrEL1dcMsI/jsO8CxZxGnd 2A15GrivKQgKio6wC7Is6l2wx1Tp2VTqyHlb8ROxPfm8+fSdhSywkn41u17s7d3RKi7n MemNNhPavHO6sAxAALBXganHPDFRDUqG6c9qIvbSQPSC4UqrXVBESrtDYY2n0NB0jEUP aQDjpx6SR0JzqBAvBjQaKQML4PsD+iaKF9fZGG0VWaO72SZMLuSVZbrUY+zYHh41HWv5 3p3MMIfpwCBKS+HbhvqaMCzffWoXa5zBTa73ziuqs+yv+vccd75YC1Xq0fvODWQK5LOq eomQ== X-Forwarded-Encrypted: i=1; AHgh+RqFBQ/IaCl7WSc4WTlLKQkFadiDZ/FNi6vF7xHDpoPKCblztwih4Qww+SOhsv1SHAWXazvqchAR+MxpUbk=@vger.kernel.org X-Gm-Message-State: AOJu0YwOjRVAxSctrfLlvqiCgk72PEZqx1GIiyLJvZ9P9FHAz+97ZGd/ 5xgtsUGjRErwx42Z6xy9i4gIEkDMUdnO8OfmlpIhYTyHqeB7J6HK6fE8 X-Gm-Gg: AR+sD13y8J5XlJfZIZR2upFxn7VSfag2AKtzNvfoSuBn+Czfx9UvDZkZ4yLbT9TFsCv oP3T9wH29BAeU1kwW46iB4KUSV/yPfMnGhO2GsSTTR8BKkoBfA5pE4hfQ2uvvhbnplltrQsVrsN bV3eaqevhTCrqq7xCmLWLdL1v2miEEuRb+Fnsr6x8Qb/Kny0XVDrnUkopgJR5Hb4NOVPY+5n/d2 7q5D78AgVtauuMre1ANI2cx9s5V3nREwiVPHCKTCMitNf49lT3V7kwXfTH+bZf/qpZnq8NcekyR b+HEW2tQpKQI7RTM5ScnPQ4pdU/nunTQDE1TaAyFlqaOHDXkAKMKijzcQLY5ajz6gw5DuIF0YVW 22N72Ncxj/6YAH874QUF6u+cqvMnMpVDw89+CphqGzt39vkZVrsDEGHMxgZWdyhlSa+YWx08y3n IGGJibGRzWRyop7AaWQcF2emtOiqRaNR9MGvVjA5cW2nSj7rRu4WSjGPfyxbjd8MJlN+33QkiZz SzzKTdiJ7vjmH2Kfcy44oD4E2LW4OfbNgBlZjg+dwr7LYAWJ0XJy/SNRNgT9xzL9jBmtleiuw7z Od2x9SXPisnVjEJJoZ5trxB+G+e9IqrvwcfpuO9KuYTjnAvGvV8A X-Received: by 2002:a05:6a00:22cc:b0:848:2c6c:dfc0 with SMTP id d2e1a72fcca58-84f2e04ea1amr6194826b3a.24.1785929966087; Wed, 05 Aug 2026 04:39:26 -0700 (PDT) Received: from spider.bream-herring.ts.net ([103.252.203.158]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cbe708c0ebesm1368088a12.19.2026.08.05.04.39.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 04:39:25 -0700 (PDT) From: Matthias Goergens To: ocfs2-devel@lists.linux.dev Cc: heming.zhao@suse.com, mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com, glass.su@suse.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Matthias Goergens Subject: [PATCH v2] ocfs2: fix cached cluster count after suballocator reclaim Date: Wed, 5 Aug 2026 19:39:20 +0800 Message-ID: <20260805113920.385959-1-matthias.goergens@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: <20260805070837.3390148-1-matthias.goergens@gmail.com> 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" When reclaiming a suballocator block group, first reduce the on-disk cluster count by cl_cpg. The current code then subtracts that new count (fe->i_clusters) from the old cached count (OCFS2_I(alloc_inode)->ip_clusters). For an allocator with N block groups, that leaves the cache at N * cl_cpg - (N * cl_cpg - cl_cpg) =3D cl_cpg i.e. ip_clusters -=3D (fe->i_clusters - cl_cpg) leaves ip_clusters equal to cl_cpg regardless of N. This happens to be correct when reclaiming from two block groups, but undercounts the clusters from three block groups onwards. The incorrect cache value is also used immediately to update i_blocks. Assign the updated on-disk count to the cache, matching the allocation and inode refresh paths. In a QEMU test using a clean 256 MiB OCFS2 image and a 10,000-file create/delete workload, the first buggy reclaim left the on-disk (fe->i_clusters) and cached (ip_clusters) counts at 2048 and 512 clusters respectively; later reclaims underflowed the cache. With this change, the cache matched the on-disk count across all four reclaims: 2048, 1536, 1024, and 512 clusters. Fixes: 4a54331616b3 ("ocfs2: give ocfs2 the ability to reclaim suballocator= free bg") Cc: stable@vger.kernel.org Signed-off-by: Matthias Goergens Reviewed-by: Joseph Qi --- v2: commit-log wording revisions suggested by Heming Zhao; code unchanged. fs/ocfs2/suballoc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c index a4a2b87a45fe3..20c3aec6b9873 100644 --- a/fs/ocfs2/suballoc.c +++ b/fs/ocfs2/suballoc.c @@ -2759,7 +2759,7 @@ static int _ocfs2_reclaim_suballoc_to_main(handle_t *= handle, fe->i_clusters =3D cpu_to_le32(tmp_used - le16_to_cpu(cl->cl_cpg)); =20 spin_lock(&OCFS2_I(alloc_inode)->ip_lock); - OCFS2_I(alloc_inode)->ip_clusters -=3D le32_to_cpu(fe->i_clusters); + OCFS2_I(alloc_inode)->ip_clusters =3D le32_to_cpu(fe->i_clusters); fe->i_size =3D cpu_to_le64(ocfs2_clusters_to_bytes(alloc_inode->i_sb, le32_to_cpu(fe->i_clusters))); spin_unlock(&OCFS2_I(alloc_inode)->ip_lock); --=20 2.55.0