From nobody Mon Jun 8 15:42:01 2026 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) (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 3AC1F39B944 for ; Thu, 28 May 2026 10:21:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779963680; cv=none; b=a4tQuNE08acIRyHx7ZeWXGLQe+jbbvhh16iAeKuznJyOyvPetccgBi7LvzLWS+B/txLWD1Afw/ysw2G2/FdyxKp1m1dyqOyAX6MhLJSkcbrnhwH25xxz0NRGnrgIkHRWqCxkBOgkv4lp6EWmCH2a0rHQHQ8NT5dKcY01piz4tRo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779963680; c=relaxed/simple; bh=jI7Cg78izFhc8YwkzdLdR1Hg35pDNSXzTk8tL+TVGH4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=Gmxuwl5MxNm+FEMFFydYkTOY+APZOrhZb2eMvq/9r8vbIVZ2KzwUiHVERfgWITIRcSSzut+z7M1u8uxYhbujhcBiSsZxARbgEaH/vTOdSEeMxD0Sa/c3X6rSXv4bRRJXZ+1GyZSeVwKcWZuDefg7LWmYpH3rC/dP9hhlVEqDPIc= 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=hViMuKTK; arc=none smtp.client-ip=209.85.160.170 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="hViMuKTK" Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-5171a8d3a1aso9024651cf.0 for ; Thu, 28 May 2026 03:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779963678; x=1780568478; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=843k2tDUPYbkxqgPxtYSJoHk8y8WS2/E2oa/7Uhir+8=; b=hViMuKTKvFIMvxu1HjuIlf3ZkD+TJ0rNrzf/ombQKk/rVbQ2PaLfxYmKiI2Wae8iUN Ex3UE1BRYRc+pI5Bchl1IVkxYWIJ9hiOt6ZiMcQ9C8Cy4mf0qpfOgvsaraa/X2u3IGNv v5QLjnYGmhLkxJCgXtul5UuQSSEERIohajkDmTNux06EM9MdM8SICU/nRc6qGPLV1QVo sec7ioTJxikaZ4mhtHMRLHR0ZYgYwHB2LzmMfVO9D9vhahMQmky6DSjjGXqAzHgHmNfX as2k23GhF16zVLO3xtGe0ikI1/+orCRtC8uF9h0f68G/mbfNG2aa51oxcZ0PQSC4zaOF Vwaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779963678; x=1780568478; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=843k2tDUPYbkxqgPxtYSJoHk8y8WS2/E2oa/7Uhir+8=; b=YfjnZCywVWjz/LlASKyVmee3rOc5+KcB7AR+fDrpGYzt2R2ALEJ5KpoLgx/f/GIOER rd2fJW/q5mu89u8i0RuLZjSL+uH+CEnkcayrUshbSO1tKg1lbo/U3Ep4BQVQ/vOhJq6k YSpkSm8UaGbLKW7CemOMBVo+ARwAPHffgxrcaFgXcyy8mhnYjJUtiMrc2djZkjybAZEa j27CMhAlB34CtRbzImI40mxlDf5KOCe6yV0z1TmidSkklB/S+wJekdaFjkx6dFIJ0mMo Fun7A4gVu7UmbDW3txUdl/HH3IjslKXXRAEbxL0vAJSILfXCxqU5cA0qGStJimqmzTAF 9HAQ== X-Forwarded-Encrypted: i=1; AFNElJ8Q9s6scBY9KUktD45D1fU4Dw90xUOCWouy4KrNmipDQdN/hwPntEfEtFXLx1AXM/61lHUo+3F40A1lbOo=@vger.kernel.org X-Gm-Message-State: AOJu0YwjtvbSfpEJs04eKYpTZ8lMJC9fG9R1z1fZKt73gM8l+4uIm+/O xXJnxN0DbXS551+NaQQWrvUofWyyY7w1hXL/3VDTMX+1JEQ5aNV0RZKTqKEZa0IMH/E= X-Gm-Gg: Acq92OF/MQumCRwh7YqAo0T2XTv3e5mD/GuXFzVENJYcLa1UV3nBaum68DVNsYEMWX4 P07GZ2ge9EfEKnwFUBwD7k5TMhQ5l/qx3jHKLCL555erkkgy09LURYaUzOYD6hkMM1Wp2cmCEap 0k+L9Q4P3QnlKLNGFktpb5IY5n4r1Hk5biU5437C+69hJGJoNG0W9L0rWouGgMH1YJJp2bC5K3a IYdyDOxL5ad27NZ2Rt1pASDRnTHC4I9dDBctE4xAeknVCy776CWw7cKhyMvf6+3I0xEisIb1yOH W/uiC4nG94lnyt5b310dKulaubaK3DmZqw/9h7W31aXaV3Vz6+9w5Ik6oUx2ni9jgtAdEMQ4QOj 6KKkXjnFpr9gndhhcuo2MivM+6e9x8qza4HbldgIQXmdRNpr+qQ5COIIF3YFTRbh1l/tLoytkRC H+ZkX2R/Lxh36/YimyAOxyhZZ3Yvuhv3bdeI0mXe3SCXSpkKAfQDQ= X-Received: by 2002:ac8:5847:0:b0:516:d83d:b28 with SMTP id d75a77b69052e-51722fe9387mr7859781cf.17.1779963678071; Thu, 28 May 2026 03:21:18 -0700 (PDT) Received: from wujing.localdomain ([23.254.208.9]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ccc4e8b923sm35754166d6.37.2026.05.28.03.21.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2026 03:21:17 -0700 (PDT) From: Qiliang Yuan Date: Thu, 28 May 2026 18:21:13 +0800 Subject: [PATCH] ext4: fix quota accounting WARN in bigalloc punch hole 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="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260528-fix-ext4-bigalloc-punch-hole-quota-v2-v1-1-32871356273b@gmail.com> X-B4-Tracking: v=1; b=H4sIAAAAAAAC/x2NQQqDMBAAvyJ77oLZVin9ivSwJqtZCIkmKoL49 4Ye5zAzFxTJKgU+zQVZDi2aYgXzaMB6jrOguspALfVtR2+c9EQ5txeOOnMIyeKyR+vRpyC47ml jPAiJneWn6ZwZGWpryVLF/2f43vcPbTyV4HcAAAA= X-Change-ID: 20260528-fix-ext4-bigalloc-punch-hole-quota-v2-2adca315d1ba To: Theodore Ts'o , Andreas Dilger , Baokun Li , Jan Kara , Ojaswin Mujoo , "Ritesh Harjani (IBM)" , Zhang Yi Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, Zijing Yin , Qiliang Yuan X-Mailer: b4 0.14.3 When doing direct I/O write on a bigalloc filesystem, the allocated extent might not cover entire clusters at its boundaries, leaving delayed blocks in those boundary clusters. In ext4_es_insert_extent(), __revise_pending() inserts new pending reservations for those boundary clusters, and the return value (pending=3Dtrue) was added to resv_used, causing ext4_da_update_reserve_space() to incorrectly release the quota reservations for those boundary clusters. Later when PUNCH_HOLE removes the DIO-allocated blocks, the extent removal path detects the pending reservation via ext4_is_pending() and calls ext4_rereserve_cluster(). This tries to reclaim quota from dq_dqb.dqb_curspace back to dqb_rsvspace, but since the quota was already incorrectly released, dqb_curspace is insufficient, triggering: WARNING at dquot_reclaim_space_nodirty+0x77c/0x8c0 The subsequent delalloc writeback then fires a second WARN from dquot_claim_space_nodirty() for the same reason: dqb_rsvspace was depleted by the earlier incorrect release. __es_remove_extent() -> get_rsvd() already correctly excludes boundary clusters that still contain delayed blocks from resv_used. Adding pending to resv_used double-counts those boundary clusters, erroneously releasing reservations that are still needed. Remove the pending variable and the resv_used +=3D pending addition. Fixes: c543e2429640 ("ext4: update delalloc data reserve spcae in ext4_es_i= nsert_extent()") Reported-by: Zijing Yin Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D221570 Signed-off-by: Qiliang Yuan --- fs/ext4/extents_status.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index 6e4a191e82191..fefe0bb8ac4d1 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -909,7 +909,7 @@ void ext4_es_insert_extent(struct inode *inode, ext4_lb= lk_t lblk, struct extent_status newes; ext4_lblk_t end =3D lblk + len - 1; int err1 =3D 0, err2 =3D 0, err3 =3D 0; - int resv_used =3D 0, pending =3D 0; + int resv_used =3D 0; struct ext4_sb_info *sbi =3D EXT4_SB(inode->i_sb); struct extent_status *es1 =3D NULL; struct extent_status *es2 =3D NULL; @@ -977,7 +977,6 @@ void ext4_es_insert_extent(struct inode *inode, ext4_lb= lk_t lblk, __free_pending(pr); pr =3D NULL; } - pending =3D err3; } ext4_es_inc_seq(inode); error: @@ -998,7 +997,6 @@ void ext4_es_insert_extent(struct inode *inode, ext4_lb= lk_t lblk, * any previously delayed allocated clusters instead of claim them * again. */ - resv_used +=3D pending; if (resv_used) ext4_da_update_reserve_space(inode, resv_used, delalloc_reserve_used); --- base-commit: eb3f4b7426cfd2b79d65b7d37155480b32259a11 change-id: 20260528-fix-ext4-bigalloc-punch-hole-quota-v2-2adca315d1ba Best regards, --=20 Qiliang Yuan