From nobody Wed Sep 30 12:16:55 2026 Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.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 BC44F37DAA9 for ; Sat, 8 Aug 2026 23:40:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786232426; cv=none; b=Y1iIXflIWi3GFEMzRc33hdtolHCIb/aUQjY4DH3qxtTSo+I2imavy6TMFPvp0tufvnfThzzkwfT4l4JbcfrlRnyAcrMqrIGSkEE9xzNzsk8b4j6sE3Ex8E7bZqwGE5PVUy/kIwTlbWO8T3GgOoL1jb3lk3CTMO4AJDfJ8cqW/I4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786232426; c=relaxed/simple; bh=eywyJoxeJiPzUZHoEDNCnRq967Hjwuh00+xW9hxuF8A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RglzeqWMvqa7iN7GtDXdMC89C8jcgUQMnKy4h7ouErjby17nmnU68idy1VmJdf69Tab8rNrDhPp2lijhw+WJq+ylXsss1CPNgXW01m9kLGd/56DIoxo4tFH7PTySGGClq6uYhRny3foVyPvNBEaASJk4aMVcy5zLhMWclwXQ9lQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peridio.com; spf=pass smtp.mailfrom=peridio.com; dkim=pass (2048-bit key) header.d=peridio.com header.i=@peridio.com header.b=yfogSeAT; arc=none smtp.client-ip=209.85.221.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peridio.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peridio.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peridio.com header.i=@peridio.com header.b="yfogSeAT" Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-5bfc4f26c67so17436e0c.3 for ; Sat, 08 Aug 2026 16:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peridio.com; s=google; t=1786232423; x=1786837223; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=0zdhFckn2ilRT1BqFxb8uQ/4LTj7nukbKKF9CpzD5YQ=; b=yfogSeATdAJnlHy0rT1dFX9cdX6ubyfo3TJIgqAyQhmpZbN7RhxSYZSX/oHKVdgZuM aN7ggig2SWFWBH3cVamEt8lLcqwVRYNCrl89w4gKGS5eo1VMDx3rWj8AnBimqlXBJFyf pajjWD5w3byhgnqFzhMm/4nMpT4IsHzNZ3m+w3Ihvc1R9bX0XNEsSJyqxO96QmgBh63y 7creSr/B0pcaSH/qlhN1lywsEh5gcwTiOn8sUul5lH1ySXNufARJa/Xz0Xgbdw0B4Pjz 0nlAi0H2mvGP5tvi1Utl5KK39P1EUPXw02jnv8MVA/RZf0iH56C0Cg01zRJyMGB3CDhP BNiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786232423; x=1786837223; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=0zdhFckn2ilRT1BqFxb8uQ/4LTj7nukbKKF9CpzD5YQ=; b=sHGuLSJFMpNY5+wLuegRTpxGf/P+mkxmEANcPyJPcqbf7dvIsJkPiJoqDtAqHYK0St b4E2yKNFNV2xJAxRTVAsqTJBReQhcavsdbGh4jEqaS/oh4m4V9No+XJnZfCJgGFHoJ2F aglTqpH6Iie0K/6JdkR62cSkECKGfkJcn+7So4nAfXgjJ4FsCbDwqS/hsW9gOVWhOlfQ QLolxfXjMr2WUivWVKopEnCtTk50CM8JyLnEjozMfdFov1+Fn0iyJk7QOm+Bi9qiXZgG /VK+nC/Xo4RCyly33Fc1Oh+AfGStO+2BfCsbInruRK0i9bZqxQ+cNi5gUTeXvqpUoIWY vevw== X-Forwarded-Encrypted: i=1; AHgh+Ro7KSbEowtIEjtdomWXRI3i60XnIcALUSlgDzR0L2a+aX0/vzwsZS1G905iUHZfCmhdUcyzmGtSVlRSSkY=@vger.kernel.org X-Gm-Message-State: AOJu0YyX0Huye9Z48D8nAjqZcgekLThDb+Sm9bPgvnsMDwR5vUcjQirU +UgDfosm5YuqwuOupYQg7T1Pr1bw2M8X9SiJ5iXc8vlFUacKwkPzuQp57iufLXRoABk= X-Gm-Gg: AR+sD13pd9glmk4aDIuSZTYn6lCRhRuBaA0G86+hpLLluhRQ773sgqUxvJ6IiRiKMDP eor7CE+imcn3FMGzt1qL/MGBHZo89tcauSMHTDPeZhitJj5i6/fMvzEzcn7Z6jrCat991eEYl+t 0ggQfkA0Bv/dLUjKVijmeP0AscH/pi5SKhBdj6ACMfmBmrUDVDbDXUsidVWlUe0Y7o3pGtFVutP o37sASBbS63xKk9W5VWrQCqN3CyASK3Eiul4p3ysAd9HOe0z4zrJ8J9vdpFvypb9qdNiy/WJMH1 jFc4As+/yuNZk8qTwN2ErgFnrcCqo2ONyFO+x8AaVw02vhiDCspK7MkORo1vUCM8k4E7QzZjQx3 t6eR204ye/1w/bQ2rxRwmcmRvjVXMeOcugyTqCCckIde3YPI+Xuje2Rm2WzXrciEF1dDAjkdv++ RJyWJu1A4OBz+AacCf7UwW1z+UUlG/SgoZzkMAEq0vVOaxpRjPKaDFJW8= X-Received: by 2002:a05:6102:b0b:b0:633:3bf6:977c with SMTP id ada2fe7eead31-760e5cbd79dmr4739370137.1.1786232423622; Sat, 08 Aug 2026 16:40:23 -0700 (PDT) Received: from localhost ([190.113.101.40]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-979f2e53fb5sm2083603241.1.2026.08.08.16.40.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Aug 2026 16:40:22 -0700 (PDT) Sender: Javier Tia From: Javier Tia X-Google-Original-From: Javier Tia To: Carlos Maiolino Cc: "Darrick J . Wong" , Dave Chinner , Allison Henderson , Andrey Albershteyn , linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH 1/5] xfs: initialise error in xfs_defer_finish_one() Date: Sat, 8 Aug 2026 17:40:18 -0600 Message-ID: <20260808234016.246054-8-floss@jetm.me> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260808234016.246054-7-floss@jetm.me> References: <20260808234016.246054-7-floss@jetm.me> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2877; i=floss@jetm.me; h=from:subject; bh=eywyJoxeJiPzUZHoEDNCnRq967Hjwuh00+xW9hxuF8A=; b=owEB7QES/pANAwAKAbXuwwuoZ3cfAcsmYgBqd75gWnthqa0dZDU1DdMYG7SucNZ1t7qzbjI67 QP0Mb4aZVyJAbMEAAEKAB0WIQSbE7ILzw7eI0VKk8m17sMLqGd3HwUCane+YAAKCRC17sMLqGd3 H9vrC/9jM099GVI/qnPe0VN8QrvIS7TxociIcdYmg/ixa9M3Z9arGeKrhQzc/8399hLqAHoy9+x ZAAZH238MBkwf2gJod3cWLc6xjfnKPkLmrdxyGpPcCio4TQmTQA2D5X3JaA/FsaulrNFjTQMjCh h6ZNctMc4bTwFUWf1TrbIhFW9UQhfSg/uk0C7Oz4gDNYx7FBa2zYKd8Ig+5JU1pAycxW0md1ZZf 2+5YAjXQqJXwwOBzawM6HJrfCWjMSzlZJ1rEU9HR+Hao/eo0/KUUmiYdcAEZirGz9EcUC2Dv69g VVwDmKslMmUrc6O3aKo2oZczzkUNyQOTlUEtvEANkpHeRjaio/mziIsJiQfcmTsdKoleBwnvRzp 8km0eGqR6tTG84EU7VWK4xiKmpRSfPx2eE84IarWtVDeUMhsyKXjNtxESZcddZFK9yCFpsG7IGx Yk9vT3DDVoZzRCZaLf+t3O9RPpBMbEqaI3Axhid5gS3br6mkg3cR5pOcXmdAzuRmQDt84= X-Developer-Key: i=floss@jetm.me; a=openpgp; fpr=9B13B20BCF0EDE23454A93C9B5EEC30BA867771F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" xfs_defer_finish_one() declares error without an initialiser and only assigns it inside the loop over dfp->dfp_work. When that list is empty the loop body never runs, control falls through to the "Done with the dfp, free it" path, and the function returns an indeterminate value. An item-less pending item is not hypothetical. Of the three xfs_defer_alloc() callers, xfs_defer_add() always follows with xfs_defer_add_item(), but the other two do not. xfs_defer_start_recovery() is harmless because it adds to a caller-supplied r_dfops list rather than to tp->t_dfops, so its items never enter this path at all, and they are driven by xfs_defer_finish_recovery() and ops->recover_work() rather than by xfs_defer_finish_one(). xfs_defer_add_barrier() is neither: xfs_defer_create_intents() walks tp->t_dfops without filtering item-less entries, so a barrier is spliced onto the pending list and is eligible to be picked by xfs_defer_finish_noroll(). xfs_reap_ag_blocks() adds one every other extent, so online repair reaches this on any filesystem built with CONFIG_XFS_ONLINE_REPAIR. The consequence is a filesystem shutdown that depends on stack contents. xfs_defer_finish_noroll() treats any non--EAGAIN return as fatal and calls xfs_force_shutdown(SHUTDOWN_CORRUPT_INCORE), so whenever the uninitialised value happens to be non-zero a successful barrier is reported as in-core corruption and the filesystem is taken down in the middle of a repair. ops->finish_cleanup() also receives the same value where an op type provides one, though no op type that can reach the empty-list path defines one. Returning zero is the correct result rather than a papered-over error, and not only because the barrier type deliberately has no work items: reaching the free path at all means the item loop drained without a non-zero error, so zero is the truthful value for any op type. The uninitialised declaration is older than the Fixes: commit below, but that commit is where the bug became reachable - it added xfs_defer_add_barrier(), the barrier op type and the only caller of it in one go, and before it no item-less pending item could exist. Fixes: 3f3cec031099 ("xfs: force small EFIs for reaping btree extents") Cc: Signed-off-by: Javier Tia Reviewed-by: "Darrick J. Wong" --- fs/xfs/libxfs/xfs_defer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/libxfs/xfs_defer.c b/fs/xfs/libxfs/xfs_defer.c index 89501e8bd2f8..843c33304441 100644 --- a/fs/xfs/libxfs/xfs_defer.c +++ b/fs/xfs/libxfs/xfs_defer.c @@ -583,7 +583,7 @@ xfs_defer_finish_one( const struct xfs_defer_op_type *ops =3D dfp->dfp_ops; struct xfs_btree_cur *state =3D NULL; struct list_head *li, *n; - int error; + int error =3D 0; =20 trace_xfs_defer_pending_finish(tp->t_mountp, dfp); =20 --=20 Javier Tia From nobody Wed Sep 30 12:16:55 2026 Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) (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 20C13382F33 for ; Sat, 8 Aug 2026 23:40:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786232428; cv=none; b=BMWPCvIMKkwY8KKRvHx8VJILkSPc9qVpSSwa5ldx6SSaeksWjMa+MnsXMlYAQJ6EtAlEkcWBtsonHegjhvItnHtw46WBJbyqPy8uvidDQoNP/dfqbmSGrqV2hAF2CN1LgEtNqcLc79EKfxnoDWwUJQOloAwmMx1Z3Id7A4bxDt4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786232428; c=relaxed/simple; bh=ywgQQybimAbetQ1b5A6qf3bB8zSZlHCCG8IDtXjEdvc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SghkrMyCbnwmKhUw5sj5X0m9agdJh7v3Rh33LDNcWjZ1JazF2KGNqwKN6hCgzxUYvosGEW2GASQs/FrvMvcPjLp5y71rY6mx864N/U0Pt0Y3fR+C2/5Ct+KC3nLddg6/jHBhua/U4HliNMceC9dHjHiKav7YlE2sT2rdDPDTU3E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peridio.com; spf=pass smtp.mailfrom=peridio.com; dkim=pass (2048-bit key) header.d=peridio.com header.i=@peridio.com header.b=wDkLS/uM; arc=none smtp.client-ip=209.85.222.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peridio.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peridio.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peridio.com header.i=@peridio.com header.b="wDkLS/uM" Received: by mail-ua1-f49.google.com with SMTP id a1e0cc1a2514c-977bdbe1410so16301241.0 for ; Sat, 08 Aug 2026 16:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peridio.com; s=google; t=1786232426; x=1786837226; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=LW37IMt7/aNr6Ztw5VvHFxxJ0NK7pezHWunpaqvkaIs=; b=wDkLS/uM9luPF2w1zNMs4ay56CjiLJjnmWFyscupdx9ovG+0ZQwNfwPTqDCvDWiWYZ 6Ap0dWfFHagk+BTujC11DBES606j7ABciMaZOW5g3cHhUdx4ZixeJh6miWsog49REZX2 YeNmApM3zQlkZNqRf4UrixRknV3ZLi7mfQF5BvBF3UWMTmErAaWSbVyvnCHtw27Okvul Foept6ZtOnkA33SDVKejilEVPRgv+Yf9ixrpm1JbNmnAymZicVaDYJzTLdB/0QtIMHb7 LcqZJ7pPF66qWJD5FS3x4bBqMtYE5Q5avtbkTDhKGJ/e9O4I7vf+qOOA2s40j0PHNo47 MhOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786232426; x=1786837226; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=LW37IMt7/aNr6Ztw5VvHFxxJ0NK7pezHWunpaqvkaIs=; b=rtK71hObdtsiWpp9WcacsCbK9vpDM5vI8nv49WoZINXBn+Wo+7GIO2id7NCOOYh4eP mcTfjCN6ijcjHf25t8pm4HYGjqWCZ3hSDD2RVVA4uElPim88sWVuPt+JCShfxUL6GBSB DU5oaXuijZMiyVESDL6LVQhr9pxaAhkfYG3Yp1t2DWfA153Dgz/8wKFWwbvd3qEy+jsX l7/JwQ+bIEnbH/IIHM2L8H/m0LmqrMtT7aCYDcjEbOFABd+Nwl0SxTGrEo7dhTPpS/tC bA409bMjUnDjt4QmgZIhYq+iukOuSR65eBGJrWkRUKkifvnDAToqg0HGcbgLCYZAN9NA ys9Q== X-Forwarded-Encrypted: i=1; AHgh+Rp3HWveY8v3T3Hfz47/6NTIOv1Q1TefAoRLw8jAXdFZ+1Kv89+iH3bMB/2F/WnUzEQ6uJToPeySyCNxFzw=@vger.kernel.org X-Gm-Message-State: AOJu0YzrcGsazL05Qcoyik+dFS5NqJabGTbJc9NJm4n8v9Gaakpb2hJT eJWXjXon2aUHLmSu7hgsxwzd3/D7qFEPC+KO6fRXQ31wZtCCYfJAa3H09PI4tdof5d4= X-Gm-Gg: AR+sD11psR+FvK6jnYdCkl/trhxkF4LPmkrEPZBXHggHLxTUok7hYSJYhrqJjmsMcBO iTqEsD6Jx81hBsWXRdhB8/Z0KUTnuPqd137n6jm7fAjMDV77/0Z/Q2970ORTrLqSRqwXY9hhSD4 2mf0yhvlhYxREXXoCzSd8IABcMQXS7l/JK18xgB32SoZKLp9jypoCuzPaI599irAgGxK8Qa5vJF GmO6sZ0l6Ine96xdIm8cfCPWSXaX6Yg2Aia105+zfH5A6zQ+CT5jJGkJi6y+pWCLYWz4uErjzcr mW5vBarJF97Cw3abVINgqXUbmNEmNxzotLhJNhAVIVEotn2VqJcA89sBTF/AYMj+WIY95/J3g+t NBI8UmBeogbKvdVh3NYY3lh6RAcq8AUF2g9QJCxeXuYZsW6fqAb1k9RvTAuRfVgseHpe8/+fiZe Zvev2sOOUzRZmeGIN2H5d6u1AqtPO7FeKjSj/EMjn4KVvL0v9DvSUtME4= X-Received: by 2002:a05:6102:f84:b0:729:5cd5:8cc4 with SMTP id ada2fe7eead31-760e8d39fbbmr4540581137.4.1786232425895; Sat, 08 Aug 2026 16:40:25 -0700 (PDT) Received: from localhost ([190.113.101.40]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-76400dfe071sm2787519137.9.2026.08.08.16.40.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Aug 2026 16:40:25 -0700 (PDT) Sender: Javier Tia From: Javier Tia X-Google-Original-From: Javier Tia To: Carlos Maiolino Cc: "Darrick J . Wong" , Dave Chinner , Allison Henderson , Andrey Albershteyn , linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/5] xfs: give the deferred barrier op type a name Date: Sat, 8 Aug 2026 17:40:19 -0600 Message-ID: <20260808234016.246054-9-floss@jetm.me> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260808234016.246054-7-floss@jetm.me> References: <20260808234016.246054-7-floss@jetm.me> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1319; i=floss@jetm.me; h=from:subject; bh=ywgQQybimAbetQ1b5A6qf3bB8zSZlHCCG8IDtXjEdvc=; b=owEB7QES/pANAwAKAbXuwwuoZ3cfAcsmYgBqd75hkyHuFdJdaJJvBanQA8vDJHIyzfr6C0JDF SLwZve0RxeJAbMEAAEKAB0WIQSbE7ILzw7eI0VKk8m17sMLqGd3HwUCane+YQAKCRC17sMLqGd3 H4C9C/9aSX0wUJHvMFvjKAOVvtRJww4qJJMkOB//QqPz+by++DLH//1CU1eSdMY0pHTlMwrFbKZ FJ6eltM8wcIhjYCBN11wyw1xX/itPHP5jj6tzsOF5RmuuCLGq/zcwstXKWw4u+kDQBgdQIJasZQ bhZKRZWrEN5uS1hTIRWJ8I9n6u7RXm0ACGDLE4xuYSDQeaiElag3dnVNCXwurf4wEmDbaRJvZcy 9TFFhBgIrF8VcxHHSAjsuI44hcaV26BkDy2spFrsN4eYI3ozC7tMmPyiarkeeacECA8XJ3fXZLE f1I3jY3ceh0PguIKZ/bxzTAKwiiburUrzpugLN1kjYrm/YEfuwYog9YrkOEC7Jz6lGDZzvE868x cMhySLjbniailI0P2Qv8gI6YICBfzs0VJz6wMHmZpGcp1EfZZav4x03YZh6WnGbMos5H6vT/9+Q wao0kMbzskKfUiBQXgL+Jzr67LMK1DxYPUwzhho7Pzs4bISqg5i9lVFbUFShsXsJP3uCY= X-Developer-Key: i=floss@jetm.me; a=openpgp; fpr=9B13B20BCF0EDE23454A93C9B5EEC30BA867771F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" xfs_barrier_defer_type is the only xfs_defer_op_type with no .name. Every other one carries a short string used for tracing and reporting: attr, bmap, extent_free, agfl_free, rtextent_free, refcount, rtrefcount, rmap, rtrmap and exchmaps. That has been harmless because nothing dereferences the field, but it leaves a NULL in a table where every other entry is populated, so the first caller to print it gets "(null)" in the kernel and undefined behaviour in the userspace libxfs build of this file, where xfs_alert lands in fprintf. xfs_defer_add() already treats a missing member of this table as worth shutting the filesystem down for, so an unpopulated one is out of step with how the file handles its own ops tables. Signed-off-by: Javier Tia Reviewed-by: "Darrick J. Wong" --- fs/xfs/libxfs/xfs_defer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/xfs/libxfs/xfs_defer.c b/fs/xfs/libxfs/xfs_defer.c index 843c33304441..75f0d37914d5 100644 --- a/fs/xfs/libxfs/xfs_defer.c +++ b/fs/xfs/libxfs/xfs_defer.c @@ -229,6 +229,7 @@ xfs_defer_barrier_cancel_item( } =20 static const struct xfs_defer_op_type xfs_barrier_defer_type =3D { + .name =3D "barrier", .max_items =3D 1, .create_intent =3D xfs_defer_barrier_create_intent, .abort_intent =3D xfs_defer_barrier_abort_intent, --=20 Javier Tia From nobody Wed Sep 30 12:16:55 2026 Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) (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 E55461E1A3D for ; Sat, 8 Aug 2026 23:40:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786232433; cv=none; b=aEYg3S4dh2wlcQsV4qDCwFIP/h62wmdQA4tTjstC3P9bmUgBigKVPfpq5fX2So6bMnRjypwWJUjgwYltgElqWJ0V9fxNvRI2OTBUXJSnTqJMjcqh6D6VzOwia/ZL5pwcnqkgNhY79shFQdXLClDwZ6juHEu70SZ5dijHaPCFSg4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786232433; c=relaxed/simple; bh=sZmYt2raO8VdDm+hOpYDP0ljGepdC6gsEluhTLQWHd4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PiOtaQNwpBo85SLQ9hV2jcu8RycIslzJTH4CfcZKdgAgYGZFlKeSWYw3H8orKgjzwFfcbIqXj2LD8ymn2j87o49zxzkU3QIWs+0mV9sU5k0d4Dil4Od4VliI6XA4gt9HmZke4SicJwCWoQQIVknQgWF7hHNhSqI6PP9ATkrXbsQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peridio.com; spf=pass smtp.mailfrom=peridio.com; dkim=pass (2048-bit key) header.d=peridio.com header.i=@peridio.com header.b=RNitRt2B; arc=none smtp.client-ip=209.85.221.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peridio.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peridio.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peridio.com header.i=@peridio.com header.b="RNitRt2B" Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-5bf8ccc3e60so24520e0c.0 for ; Sat, 08 Aug 2026 16:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peridio.com; s=google; t=1786232429; x=1786837229; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Nyeyac7LrDv4OnnnUjx1xvNsyZmRbR/sEbRM05AokQ0=; b=RNitRt2BFB3jecBaQIKeTMPxf3ziAOkjS9aSgUUWB0LESgmdzH7N6Ili52e9qhjsqC Yrn4mEoX4Qmd68c0kCy/fFsShZwlBJaHMYLCvp0o8PWQeOnHXlz/aPxVYjsHR3XuVs9Y mRpGL5a4EkAVBpW/snIitgxDFA9lLvJP6hiFLYx9bjmYAhI3faST0buq+8NnXklMfB18 ZaXX1oMC5f/WWzWirFZ5wISPqn3Kp3u++S0QjWe42s+FjiaDIKXqOh2XWUedH9xbuGyx 98j8HtPm2SYPW1CSaSZxvGmFoj88cCbdsfAGRkrNhcPntd1tNQdO3TUgndOVQ8IYn+op QEEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786232429; x=1786837229; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Nyeyac7LrDv4OnnnUjx1xvNsyZmRbR/sEbRM05AokQ0=; b=iN4/Xcth1sp9zg5CRWBuWHuJNbk4GuJZablAC6TnFXiJe+UCiqp4REL+LCFAaVBDFV 5+zZP3zl82+9iztKARskitQRq6MHUDtL+AG0HX1R8AQEjofQRJvQ/nAxxa2ZAxlovTsG rxOy5knNMXLFgn89o7S/UB2w9PR78qUSFwr4uNk1fSWTpaullpzw2r+k8nL78jb1wOkr nPSvetANKDTAa3UDojKMs8xbQ72Wa9+MtjScEwD3v5khG46TlKpTHTRuEhSAmyOgM4k3 UlygX4kuv3JmiFAFbc8MT7j+45HoxCJIhmeMcENDRUotBDl5wWRHyFDC249nYEzA3IBo mbrw== X-Forwarded-Encrypted: i=1; AHgh+Rqx8D3gZLk4L4hS37Jq5OKxe/EvEkcL72INAX8Tu9qsKoSgYYcVzhjwvHsbf1b2jxheCYTvGQDDwXuXh/c=@vger.kernel.org X-Gm-Message-State: AOJu0YzssgRRoQOjHfPLj8wV+JyCWSNQMcOI2GPsQvF5US0MkdzmGZh6 mquIkd5BW/U8nQmg7fKtqZxgX8f9q2OEsc6XcaxByczUGFYfHd+ijTIfHd8fP3+IUO4= X-Gm-Gg: AR+sD11Ib4rhhDpmR+7IWIBCDWX+nHevpaLkK/rcpfZIZZRwAmj2x157W+t0dUQW49I XZ4tB67x+GJZOYdu1o+9KgV2w9xPSLYaxyBkdSYPjdDSxwZF7bhobH8NDIK8Ip3esGMQBvcOG+9 +jXj5ZoEdr80zlnTN5HKt3YTTOOevtFgfVD8QoCa/jwEz9uMpRankct9mxkGlBfDcHh0bj83y3/ drTly4WUGMh7mKFHgm9/Skr9Nsakx+Yu+tYJglP9pKOXBi/vk+Dpdlo2gHwmW24RWRna5SNsT3v UzYTenXzBcMoCDotDYXzKygf35Zi9LxsMbCs8oWqPAIXB1IPGZMHzidcntav9WDm4D+OPwiBwBR otg1/sZosIjzSwTfvmG9bcblNJ8th3Ssp1GjH38zX7FXD1YvICNgcB6SER6DK1HlwjjSX5LsG/a YwfoSOvDzkrCq+Fayj3WBLPalQvpEEEVBqaL/Booww+Slr2o3PqgvxIxqWz2gJWbP7a2tQZvVGP AQ= X-Received: by 2002:a05:6102:d8a:b0:6c1:6ef9:db9d with SMTP id ada2fe7eead31-760eab487cemr4716210137.3.1786232428639; Sat, 08 Aug 2026 16:40:28 -0700 (PDT) Received: from localhost ([190.113.101.40]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-763fe4da46dsm2793059137.3.2026.08.08.16.40.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Aug 2026 16:40:27 -0700 (PDT) Sender: Javier Tia From: Javier Tia X-Google-Original-From: Javier Tia To: Carlos Maiolino Cc: "Darrick J . Wong" , Dave Chinner , Allison Henderson , Andrey Albershteyn , linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 3/5] xfs: report the error that made deferred work shut down the fs Date: Sat, 8 Aug 2026 17:40:20 -0600 Message-ID: <20260808234016.246054-10-floss@jetm.me> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260808234016.246054-7-floss@jetm.me> References: <20260808234016.246054-7-floss@jetm.me> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=5410; i=floss@jetm.me; h=from:subject; bh=sZmYt2raO8VdDm+hOpYDP0ljGepdC6gsEluhTLQWHd4=; b=owEB7QES/pANAwAKAbXuwwuoZ3cfAcsmYgBqd75hWc2ucnGB2iLvPGY7GFwsoX7z/tvck4NsP BrXDiEHud+JAbMEAAEKAB0WIQSbE7ILzw7eI0VKk8m17sMLqGd3HwUCane+YQAKCRC17sMLqGd3 H1LNC/4wKA7riBK0Lx0jjbe0pLAuX6QzsUcBNOdymajX9QLvjjH6tAAjtCv7Mv3KMdbCSWGyL9E nJvNON+EFJbab9DgT8cM9FCkvxLG0ovXjHXm3nFSOYMAPbFnIEavy2lOAXmqI6KG15UyVGCOMMr k3deGaw381LAgy2PnKKV68UV51F5qposNKjQED/qAsHsgmZcoLRMGdGZKKc7UemUwktlenfCEYE owXgdz3atyiAM7OwHRAEb5SvtoVg7DQh10kgTEHWMZzAOmzkSN8rsjjstvgoj4b/rArqYIfqzwn M0UvGii4ZavqIhx1QYNyQGfRPQb5uXT5OLamHmmU52lG2N50NiKIqB8JRYnSMVwqRbQOFApb8Wv Ic0xMv5TYi6zvWqV8NvOgHd/iQqJVXa2xs5/rFAH8Z0d1d8EaIS4InyMOBn3JBUzF6QnW7lG2b3 BT8dJaAW9qnOBvYHx5RKSVuCAIKjCq0lOakmcSq2AL8izLH9cXa8D4ADziW/oe+EkzIPk= X-Developer-Key: i=floss@jetm.me; a=openpgp; fpr=9B13B20BCF0EDE23454A93C9B5EEC30BA867771F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When xfs_defer_finish_one() fails with anything other than -EAGAIN, xfs_defer_finish_noroll() shuts the filesystem down from a generic out_shutdown: label. SHUTDOWN_CORRUPT_INCORE makes that surface as "Corruption of in-memory data (0x8) detected at xfs_defer_finish_noroll+0x29a/0x4b0 (fs/xfs/libxfs/xfs_defer.c:721)", naming neither the errno nor the deferred op that produced it. Any error from any deferred work item lands on that one line, so the report is equally consistent with a transient -ENOSPC, an -EIO on a metadata buffer, or genuine in-core corruption, and there is no way to tell which from the log. trace_xfs_defer_finish_error() records the errno, but it is called after xfs_force_shutdown(). With fs.xfs.panic_mask carrying XFS_PTAG_SHUTDOWN_CORRUPT (16), the first shutdown reaches _xfs_alert_tag(), which BUGs, so the tracepoint does not fire for it. Later racers do reach it, because xfs_do_force_shutdown() returns early once xfs_set_shutdown() has fired, but by then the errno belongs to a secondary failure. The informative one is lost, and that is the configuration used to capture a crash dump: recovering the errno from a vmcore means an ORC unwind of the xfs_defer_finish_noroll frame to read the callee-saved %rbp that happens to still hold the value. Move the tracepoint ahead of xfs_force_shutdown() so it is reachable for the first failure, and report the same information through the log, because the systems that hit this do not have tracing armed in advance. Report t_blk_res as well as the errno: how much of the reservation is left separates a transaction that ran out of blocks from one that never came close, which is the difference between suspecting whichever xfs_*_space_res() fed it and moving the search to the allocator or to the buffer that returned the error. It cannot say more than that, since xfs_trans_dup() hands each rolled transaction the unused remainder, so a small value is also what a correctly sized reservation looks like several rolls in. t_blk_res_used is not worth printing beside it: the new transaction starts at zero because xfs_trans_dup() allocates it with kmem_cache_zalloc(), so it reads zero on the roll paths and counts only the current segment on the others. Take the op name in a local read before the call rather than from dfp afterwards. dfp is freed once its work list drains, so the name has to be captured while the item is known live, and it has to outlive the item to be available at out_shutdown for the paths that do not come from xfs_defer_finish_one() at all. dfp_ops points into a static const table, so the string itself outlives everything. Clear the attribution once an item finishes. Three of the four paths to out_shutdown - the create_intents failure and both trans_roll failures - are reached at the top of a later loop iteration, before any item has been picked, so a name left over from an item that already succeeded would blame it for a log commit that failed afterwards. That is worse than the generic message this replaces, because it invents a lead where there was none. An -EAGAIN item keeps its name, since the roll that follows is part of completing it. Skip the alert once the filesystem is already down. Only the first failure is informative; everything after it is a consequence, and xfs_do_force_shutdown() suppresses its own message for exactly that reason. Testing xfs_is_shutdown() rather than rate-limiting keeps the first report unconditionally and drops the ones that follow, instead of a token bucket that could spend itself on another mount's failures and discard the one that mattered. Signed-off-by: Javier Tia --- fs/xfs/libxfs/xfs_defer.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/fs/xfs/libxfs/xfs_defer.c b/fs/xfs/libxfs/xfs_defer.c index 75f0d37914d5..bbf2f4ca3c2e 100644 --- a/fs/xfs/libxfs/xfs_defer.c +++ b/fs/xfs/libxfs/xfs_defer.c @@ -656,6 +656,7 @@ xfs_defer_finish_noroll( struct xfs_trans **tp) { struct xfs_defer_pending *dfp =3D NULL; + const char *what =3D "deferred"; int error =3D 0; LIST_HEAD(dop_pending); LIST_HEAD(dop_paused); @@ -705,9 +706,17 @@ xfs_defer_finish_noroll( struct xfs_defer_pending, dfp_list); if (!dfp) break; + what =3D dfp->dfp_ops->name; error =3D xfs_defer_finish_one(*tp, dfp); if (error && error !=3D -EAGAIN) goto out_shutdown; + /* + * A finished item is no longer a candidate for a later + * failure. An -EAGAIN one is not finished, so it keeps the + * attribution across the roll that completes it. + */ + if (!error) + what =3D "deferred"; } =20 /* Requeue the paused items in the outgoing transaction. */ @@ -719,8 +728,12 @@ xfs_defer_finish_noroll( out_shutdown: list_splice_tail_init(&dop_paused, &dop_pending); xfs_defer_trans_abort(*tp, &dop_pending); - xfs_force_shutdown((*tp)->t_mountp, SHUTDOWN_CORRUPT_INCORE); trace_xfs_defer_finish_error(*tp, error); + if (!xfs_is_shutdown((*tp)->t_mountp)) + xfs_alert((*tp)->t_mountp, + "%s work failed, error %d, %u blocks reserved", + what, error, (*tp)->t_blk_res); + xfs_force_shutdown((*tp)->t_mountp, SHUTDOWN_CORRUPT_INCORE); xfs_defer_cancel_list((*tp)->t_mountp, &dop_pending); xfs_defer_cancel(*tp); return error; --=20 Javier Tia From nobody Wed Sep 30 12:16:55 2026 Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) (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 5D3C237BE80 for ; Sat, 8 Aug 2026 23:40:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.177 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786232433; cv=none; b=LtDKz591KuvXbDJDdtLw7tvvLVlFF3T6uSnBStte08Q8oZpVXHI3KY/FCO/J4oNr3KgPOV9nTGQ2sA9FUlzaprn4nMzgcpkz1cMieNb9BRgqxmXvPrVc8r4epmx5nmCb+PSt6ajXKvSKGwL901hj1kkjcY+1pvWR51mMNNSk2Iw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786232433; c=relaxed/simple; bh=bXl+qTSekfMI76nQMOaAgji96J8fMd0LAgDdt+hbuRA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sMPOuAKvYn4klYFgU3YAt5P4Ea3y1rn8mP9EyBQI/dRkqIYttDuJOS1RXDvSqJ7Ok4D50uaErVH7t+IfqMXibxdJ5bo0U//efVeV1urQlSHdmh4eRXSFV1crYBGaJHd8V2zNdckjXiFwYOtY4X9KsWsVXueG7usUNMGxg3/cX7U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peridio.com; spf=pass smtp.mailfrom=peridio.com; dkim=pass (2048-bit key) header.d=peridio.com header.i=@peridio.com header.b=iZdG2NgZ; arc=none smtp.client-ip=209.85.221.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peridio.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peridio.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peridio.com header.i=@peridio.com header.b="iZdG2NgZ" Received: by mail-vk1-f177.google.com with SMTP id 71dfb90a1353d-5bf88d3fc8fso17208e0c.0 for ; Sat, 08 Aug 2026 16:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peridio.com; s=google; t=1786232431; x=1786837231; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=JfnxvWXI36e8f0gw6H7fpo1CGOl18GKzKKkOiq2dJb0=; b=iZdG2NgZyHyAblm6FTxW0Jj8ZNCo2SDtUxAtjI8IwBjO365aGN887uzXb/sA2q9Tq/ 8ohfjKaDSbiiojbnJ9tuugYZixn8ZEW2L7o7OJnnZZhIcdb93466ReJLh/Y52b9PG8qO rqVeDfFAZRdtXvDXTsEawojpjyUFwvY8gqaSCQIMJyHktDFvXK6ZfC19CGwg4b27Hkxh UkilaW+QcFGKa747KvijGhIpo/NBITGF+GEdDW959MaZ9F4+Zym/Ycs2majUXxAxMVJy Ziu1gY/2akoHv4ImqPylATc0sS0Fwa7xqdbo7ZN2XobypGvSGlXwfIPyyhGE3X3UJ5q7 ZWNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786232431; x=1786837231; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=JfnxvWXI36e8f0gw6H7fpo1CGOl18GKzKKkOiq2dJb0=; b=kWER9kP98R/nqJmfqxVaBizuWMTSzcXbiNLWCsXZ/hsL21oA6/mDCd43XDv2viUxd3 IbPpGPnN2fHhNAiHJv6otgDIu0KjZFXJyrzsCqA/A+eR2F4gN0kLWK3Hbx/PaTunkGPy ftqPauBfOG5sTvSWnQqpc9iyhAleMXQQkw1MRafuK70DBA88W86sQqFez3Zo73cf8G8I nXanz5NeWsbuftS1/9HtQ7in1d79iFRh9j1miz9iQeax3VX2u88G/6gBT08WXCzuHuQ5 jjZI88LFUsVyFi78ecUQRcYiwam4p5SMq+Xyuas4cAFAsuCavZ/9RkaP7fLfZKI5eZkO +KxA== X-Forwarded-Encrypted: i=1; AHgh+Rp8TNVYudrtTyf8hG1AWIDHBWKEbLCNlaEGVAKXSGSC2TXOrCFaD9rToz+wrX56XK43+xHmE1KucivmQIc=@vger.kernel.org X-Gm-Message-State: AOJu0YzI3mfBdCrDE/wlA44Cp3cYUsDlLXQudnS6qy9//oOIC+zHowBv sPrvfqcIhSosaJbX7VB0qenDr127L9U+nUFU4tvV6VFwMSW84KmwN98C4QvbmkI1rJs= X-Gm-Gg: AR+sD13XI/EOIDjxjalBDBtM/kTcs3pgSExrXdjhsFRdOHlrUMzufeix7PtE3jXPc0Z FLWLayAErTowy4RlDDJUPSVvnQ4TTq8KgLPoif4YUARfl2Z6Sh0f0fl7+L3y85n+I8Ih9B8dB00 Fxey6MJbztYqp/cU9X9LPbSZMFW6lRuh5OszWwIItIuTJwY4c6hbMxg5IRkDdGrKmOBoHPNhcAK woecOc4Ym87W+UfFwMIoPuRtwXFWoobfA2BuTBgtodDwR8vOyrB9LOTOVHHjNEBXy5Skh6cvviP D0riPuGKOBXRCdwkZdVczquXT8NbXlXsLJFGcRUJtt4jPK3T3s26+SHyVGkaWGpnZVkBEnxTEEQ 5aB+AT5rDXpiIdqJ8+HfOxq//HioYP+gWTCwTs6LVExcjVgpj2NnElxd8IXh+jaiWSz1D1l0+h2 OL5xvO7T/EYPw2wKJ3gH/FKBnxXZ5z/ZTz8+J2w1EaZQpPHTPE6Eh+sllFuSjJqT03 X-Received: by 2002:a05:6122:6b8d:10b0:5c3:6e8a:4a22 with SMTP id 71dfb90a1353d-5c3d940b089mr2617912e0c.3.1786232431272; Sat, 08 Aug 2026 16:40:31 -0700 (PDT) Received: from localhost ([190.113.101.40]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c40b1a7e95sm2634346e0c.12.2026.08.08.16.40.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Aug 2026 16:40:30 -0700 (PDT) Sender: Javier Tia From: Javier Tia X-Google-Original-From: Javier Tia To: Carlos Maiolino Cc: "Darrick J . Wong" , Dave Chinner , Allison Henderson , Andrey Albershteyn , linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 4/5] xfs: correct the parent pointer space reservation comment Date: Sat, 8 Aug 2026 17:40:21 -0600 Message-ID: <20260808234016.246054-11-floss@jetm.me> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260808234016.246054-7-floss@jetm.me> References: <20260808234016.246054-7-floss@jetm.me> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3996; i=floss@jetm.me; h=from:subject; bh=bXl+qTSekfMI76nQMOaAgji96J8fMd0LAgDdt+hbuRA=; b=owEB7QES/pANAwAKAbXuwwuoZ3cfAcsmYgBqd75hXV/oVr9sQgFq7E3EglP/MSpHHLC6rElVU hYYMxeQqv+JAbMEAAEKAB0WIQSbE7ILzw7eI0VKk8m17sMLqGd3HwUCane+YQAKCRC17sMLqGd3 H2YUDACYGG0Qp9hRvlYZATPjI/4J5lecxM8q0DoyWscsNAk1JlErH1M+ZCNQys/8OIDIhJdfl8q 39K8/JvCt/0zJ3kyqvh02sjgjXvOGlBcTxsWMjwBociHdquHOOm8jJ4ndyhmU1MUljzmSdvhlV/ d6x/e0Fc8Yaq3eXpcW8h6Q/qsDhBymaX4jTyln9rf1whFvQTWoqHAUILbkJ+vIVbMiJeg9MpmcY Xli3O890Q+YZorxAi1tVb3+D9XRD2FB6eJQpgQD0OjFCLclxh5ksOAU43bkzsjHO2FFkDQwbnDu KySMlUWapWyQ82CKUx5BhdUe8d/llcyVkiNbkfuEc80sjZGhSMWhoKjr/dT/5eH8r394q0jHl4I z/VQJfkxBX//DDI98uphQUIBEzU3lGXWLybnkQA6sz7UTjMEtme8tuMlHyVSC+N/gDz2KuxXRPx 6sjk/VZO9AHd//amClYQxSpHsEvLE6Ip8Fscjqt7wO143u+UaaiIByAyYlMpJVg9hWlMs= X-Developer-Key: i=floss@jetm.me; a=openpgp; fpr=9B13B20BCF0EDE23454A93C9B5EEC30BA867771F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The comment on xfs_parent_calc_space_res() claims parent pointers are "always the first attr in an attr tree". They are not: a parent pointer is recorded per dirent, so an inode with N hardlinks carries N of them, and `xfs_io -c "parent -p"` on a 31-link file lists 31. By the Nth link the attr fork is in leaf or node format and the insert is not into a fresh tree. The reservation itself is fine, which is what makes the comment worth fixing rather than the code. XFS_DAENTER_SPACE_RES() reserves XFS_DA_NODE_MAXDEPTH blocks plus a bmap allowance for each, i.e. enough to split every level of a maximum-depth attr dabtree. That depth is a format ceiling, not a runtime property, so the result cannot depend on the format the fork happens to be in. Anyone auditing a reservation shortfall here reads the comment, concludes the sizing rests on an assumption that demonstrably does not hold, and goes looking for a bug that is not there. Record why no double split allowance is needed either, since that is one of two visible differences from xfs_attr_calc_size() and is not obvious from the expression: a parent pointer's name is a dirent name and its value is a struct xfs_parent_rec, so the leaf entry is local and at most round_up(3 + 255 + 12, 4) =3D 272 bytes. Parent pointers require V5 and therefore XFS_MIN_CRC_BLOCKSIZE, so the smallest half-block this can be compared against is 512 and the double split branch is unreachable on every mountable geometry. Locality is decided against a different threshold, xfs_attr_leaf_entsize_local_max() at three quarters of a block, which the 272 bytes also clears. Record the other difference too. The second term hands a byte count to XFS_NEXTENTADD_SPACE_RES(), whose parameter counts mappings, so it asks for more extent-add allowance than the one mapping a parent pointer adds. The factor depends on the block size, because the macro divides by XFS_MAX_CONTIG_EXTENTS_PER_BLOCK(), so the comment says only that it over-reserves - a patch whose whole point is that the old comment stated a geometry-dependent thing as invariant should not do the same. That it over-reserves is why it is not a bug and why this patch leaves it alone. Signed-off-by: Javier Tia Reviewed-by: "Darrick J. Wong" --- fs/xfs/libxfs/xfs_trans_space.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/fs/xfs/libxfs/xfs_trans_space.c b/fs/xfs/libxfs/xfs_trans_spac= e.c index 9b8f495c9049..c4cd547033e5 100644 --- a/fs/xfs/libxfs/xfs_trans_space.c +++ b/fs/xfs/libxfs/xfs_trans_space.c @@ -22,8 +22,23 @@ xfs_parent_calc_space_res( unsigned int namelen) { /* - * Parent pointers are always the first attr in an attr tree, and never - * larger than a block + * A parent pointer is recorded per dirent, so an inode with N links + * carries N of them and the attr fork can already be in leaf or node + * format when one is added. That does not affect the reservation: + * XFS_DAENTER_SPACE_RES covers a split at every level of a + * maximum-depth attr dabtree, whatever format the fork is in now. + * + * The name is a dirent name and the value is a struct xfs_parent_rec, + * so the leaf entry is always local and never exceeds 272 bytes. + * Parent pointers require V5, hence a 1k minimum block size, so the + * entry always stays under half a block and this needs none of the + * double split allowance that xfs_attr_calc_size() makes. + * + * The second term hands a byte count to a macro whose parameter counts + * mappings, so it asks for more extent-add allowance than the single + * mapping a parent pointer adds - how much more depends on the block + * size. It over-reserves either way, which is why it is left alone: + * correcting the unit would shrink a reservation that is only generous. */ return XFS_DAENTER_SPACE_RES(mp, XFS_ATTR_FORK) + XFS_NEXTENTADD_SPACE_RES(mp, namelen, XFS_ATTR_FORK); --=20 Javier Tia From nobody Wed Sep 30 12:16:55 2026 Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) (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 9D7D83806C5 for ; Sat, 8 Aug 2026 23:40:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786232437; cv=none; b=RrYyKgfAW2nWGKl6oWIEdvX0Ly9WzYN/2eQEeboWR8gSSWB5KxNfmnNNtBcqxemJJ6QxuO8HaW2NGzDzyai3FAfQwJhVtxEAjpYbPmkFbVxON9/Ucrmt2DIsDT7kBFHPDGxgScnbNRUPYdVYyiT9A5y4dxv408hVwWPY6UuAYcI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786232437; c=relaxed/simple; bh=RLoC+bLWmhMUbHM0JWWMbn4Gk548Sl3f/pkuN1JQxy8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Q+kORMypC+icyHrFc572RjrkLAZ7wcAXp0w64bfSpDTntKRw30jsbx7KPwntJPaVXjcmx5qmQGTSdEOOhrJXXF8tTTQSICshbMhfEHuyYZybh4bD9QpfKtn+RwnfBerP1UXSlpLczLYyYXX99U9j1qEnbbz+c3TeXHc6WtgH0V0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peridio.com; spf=pass smtp.mailfrom=peridio.com; dkim=pass (2048-bit key) header.d=peridio.com header.i=@peridio.com header.b=zCeIPPRv; arc=none smtp.client-ip=209.85.221.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=peridio.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=peridio.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=peridio.com header.i=@peridio.com header.b="zCeIPPRv" Received: by mail-vk1-f181.google.com with SMTP id 71dfb90a1353d-5c2e66ecbc1so13378e0c.1 for ; Sat, 08 Aug 2026 16:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peridio.com; s=google; t=1786232434; x=1786837234; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Y8m07bJ9x4UZg3CIvhKYlzzd3b76M3lyayd1caP+7UA=; b=zCeIPPRv2af97cTLAYBt5YyBYrFTaFBpdBz2uErHxcxmRq9bhpNnnww8L4M7iqm4xM KRhTNILxK35TtYcVxBp9xwmUgIr+CGoF1o3RwIPdDaZocPt0r8x2QIdXZQVZHXTrmnwF eN3pjFU3vqGY83Geq2gE2U4CtreFWfy4MJ9OBUxrmInMCPL/sXMAblgKSsii1robPwjV 4IG8yOSxMI8tLuLPTUn+p9rZXu/GdrWzNCxKN8xzb4HsxWTsMDfwqCJwGKuJgm2KQmL4 UoI+9Lp6KRp1h/eanPmbYGrUr57mmKwQW1OQbpgwgHJG+iPJ/JApIGj5LKbRLjqr1OeH /jjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786232434; x=1786837234; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:sender:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Y8m07bJ9x4UZg3CIvhKYlzzd3b76M3lyayd1caP+7UA=; b=WjPzgyF/AM/a8r5abXzGS01aPhla559ItUSe6zogXq+oct/YiyqEjkwooEeUthHEOs n/rhYxlAQYOpL3Jat/p31afvG9rtTk3Gii8O4UT3kDmYVMnBXQ7+w79zxFNh9QSnAp0O NGS4/49TWYXK7aCfTCFabImeJOltI6OKEFxqR5vlLTYa6cKTJRLt/hcMx47htf1gaQSY Y0IIz3K8fuPlAr2j/SiWO500/VNgM1DEagvVDUcxDqIHvVp49ZsomfIx/cHbFRSxQwRO JLrmbZBW1gmnUv1H4xLkiXkQ7i9S2VoRWLd85OmZAZzHNtrwhbeXwLbrZYZlQcHN+UME IztQ== X-Forwarded-Encrypted: i=1; AHgh+RpTw6zphNLrQhIMo/5hdA7sNN4uPquqebXaTf7Hmw5ZOnOeISGvKv1k5GBVkh3RJMrsbNOiSJkLyPnVsk8=@vger.kernel.org X-Gm-Message-State: AOJu0YyuajvkBkfF5ymK0vJyQ5XZyD6q+JEvxvy/tpyod05jRiWrAoD7 K/BHirO4fKuEu2bEzk24KvvWP9/UjQVCeaIE9TOD8nwKUYP+w8rJ4Ua7V/7WRpIz5iI= X-Gm-Gg: AR+sD11TW44R1N15Y2ysqKjTCL+ECMej65TqV+1EucZl2uMnxWRoYry2TEFT/T9C4um ZRF64to3AfgjuC0KwD8v4Bw+ydv4n0J6vLMHTNHa0G6OhJZEK5t9Kh9na7FIfSBKnNreMGGX0+i KQL+gzr111NYP5uJo6gszL0W5+lZwv6h8WkPWJhOg7Gxt1hWMhl8bhWapaHIdT/ziFMWAPw2c+e dvaqCjnWOhqxQFSEEuxbuvrVsd6rF/zpJo87nBpr4A1PCWpj29W9L+e3abn7gKzn5r3wL6EGpXN Y4IUb/CVi3nD3tdI1atEFYcYGEpT/e8yBGMpl/8t96o3iA9QBt5LWG8rxqkM6dJ3/HcWOP4QOfq pWNdHk5YQ8tqjokzfDaL4hFFVFgSXQaYLy95/xxMbzDKxBX2oya2b4qeidl0e9mvpqIakJGSky2 LV5khxkZ+m62k6MxkXKJkS4899Ba1rfX29V6MNpjycXGJj+R1B+M0DWgmLRBmBiXD5 X-Received: by 2002:a05:6102:3ca3:b0:740:2974:57bd with SMTP id ada2fe7eead31-760e3aa3f3emr4976841137.0.1786232434470; Sat, 08 Aug 2026 16:40:34 -0700 (PDT) Received: from localhost ([190.113.101.40]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c420a2d1d8sm933268e0c.6.2026.08.08.16.40.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Aug 2026 16:40:33 -0700 (PDT) Sender: Javier Tia From: Javier Tia X-Google-Original-From: Javier Tia To: Carlos Maiolino Cc: "Darrick J . Wong" , Dave Chinner , Allison Henderson , Andrey Albershteyn , linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 5/5] xfs: initialise args->total for parent pointer updates Date: Sat, 8 Aug 2026 17:40:22 -0600 Message-ID: <20260808234016.246054-12-floss@jetm.me> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260808234016.246054-7-floss@jetm.me> References: <20260808234016.246054-7-floss@jetm.me> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=5235; i=floss@jetm.me; h=from:subject; bh=RLoC+bLWmhMUbHM0JWWMbn4Gk548Sl3f/pkuN1JQxy8=; b=owEB7QES/pANAwAKAbXuwwuoZ3cfAcsmYgBqd75hNCWMnc2GW9Tosbw5mgnh76chi8Q/9CHct MWOgEqnUOuJAbMEAAEKAB0WIQSbE7ILzw7eI0VKk8m17sMLqGd3HwUCane+YQAKCRC17sMLqGd3 Hx3PC/4tWC6hsXgROpveLtrgXEFBsGRGw8KoQGxduMqxlaPyqbGNlIERhaLzvu0896EZskS4on2 hkiUU0Cys5SwcBrfHfphNGS3rqpGcCqscX/HGhkhVLerdsUq7NS0QYUcMWv9xVKfgeTvgAunky3 lID43hGjAiu88VKwv6m2xL67qnpb8cvq8DnmS6DrkkzNDriHzWVjXSBZw061L1JVdj6g2ONusva GYk8LRldTwPI/LQmohvT8uXAqhktP0cQxFQLYkOJJFr1d94FX83azTmORbjmz8leOdN/Tgz9JRK KOpSMNPGxhs8DcVBx0uIr/WXdmBpTCRnWvHp+jV59WEymrhtdEa+SL9bsPovRy2Td0CkRsW7BRJ yXX/0AkVHFN3OynPaS/uZBNdbTexEItdYksSsqk8ke8gIPZH9L3r3bOwnxTonrndHPlwuywGjas IT8ITNSMnAyJG6fyvIXp12ZSkWpdtkBRVCzUJkWBzzID/CY4NRTIi7GZd6rSG6+2dPJ1s= X-Developer-Key: i=floss@jetm.me; a=openpgp; fpr=9B13B20BCF0EDE23454A93C9B5EEC30BA867771F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" xfs_parent_da_args_init() fills in every field of its xfs_da_args except total, and the containing struct xfs_parent_args is allocated with kmem_cache_zalloc() (xfs_parent.h:66), so runtime parent pointer updates reach the block allocator with args->total =3D=3D 0. The log recovery path already gets this right, which is the clearest statement of the bug. xfs_attri_recover_work() reconstructs the same operation from a recovered intent and does args->total =3D xfs_attr_calc_size(args, &local); /* xfs_attr_item.c:706 */ for PPTR_SET and PPTR_REPLACE, and deliberately not for PPTR_REMOVE. So replaying a parent pointer insert from the log runs with a correct total while performing the same insert at runtime runs with zero. That field is not a constant. xfs_da_grow_inode_int() treats it as a running remainder: args->total -=3D dp->i_nblocks - nblks; /* xfs_da_btree.c:2388 */ xfs_da_args.total is an xfs_extlen_t, i.e. uint32_t (xfs_types.h:14), so subtracting the first block the attr fork gains wraps it to 0xffffffff. It is passed down as xfs_bmapi_write()'s total argument (xfs_da_btree.c:2348), stored as xfs_bmalloca.total, copied to xfs_alloc_arg.total (xfs_bmap.c:3214, 3379) and finally reaches if (available < (int)max(args->total, alloc_len)) in xfs_alloc_space_available() (xfs_alloc.c:2525), where the cast turns ~0U back into -1 and the minimum-free-space test can no longer fail. Parent pointer allocations therefore skip a check that every other xattr allocation observes. Growing the fork twice in one operation is ordinary, not a corner case: XFS_DAS_LEAF_ADD calls xfs_attr3_leaf_to_node(), which grows the fork (xfs_attr_leaf.c:1319), then sets XFS_DAS_NODE_ADD and returns -EAGAIN; the next cycle can reach xfs_attr3_leaf_split() (xfs_attr_leaf.c:1462), and a node split reaches xfs_da_grow_inode() again by way of xfs_da3_split() (xfs_da_btree.c:748, 866). The xfs_da_args lives across that roll, so the later allocations are the ones that see the wrapped value. Set the field from xfs_attr_calc_size(), matching both the recovery path above and xfs_attr_set() (xfs_attr.c:1150), rather than clamping the subtraction, which would leave total meaningless for parent pointers and hide the omission. The initialiser is shared with five other callers and the value is inert on all of them. Every reader of args->total in the attr code needs xfs_da_grow_inode(), whose only attr-fork callers are the three growth functions in xfs_attr_leaf.c and the two split functions in xfs_da_btree.c, and the state machine cannot reach any of them from a remove: each remove state completes with xfs_attr_complete_op(attr, xfs_attr_init_add_state(args)), and xfs_attr_complete_op() replaces that add state with XFS_DAS_DONE unless XFS_DA_OP_REPLACE is set (xfs_attr.c:497), which only the two replace helpers ever set. xfs_parent_lookup() never allocates at all, and on xfs_parent_set() the assignment is immediately overwritten by xfs_attr.c:1150, so it is dead there rather than merely unused. Setting it unconditionally is simpler than mirroring xfs_attri_recover_work()'s switch. This makes the allocator stricter for parent pointers rather than only more correct: where total was 0 the test reduced to available < alloc_len, and it now asks for the whole remaining reservation, 25 blocks on a 4k-block filesystem. That changes which AG is chosen and can cost an extra allocator pass, but it does not introduce a new failure. xfs_bmap_btalloc_low_space() retries with args->minlen and sweeps every AG before declaring ENOSPC (xfs_bmap.c:3511-3532), and a parent-pointer link never runs reservationless in the first place - xfs_link() refuses the resblks =3D=3D 0 fallback while pptrs are enabled, precisely because it cannot back out if the xattrs must grow (xfs_inode.c:948-954). Fixes: b7c62d90c12c ("xfs: parent pointer attribute creation") Signed-off-by: Javier Tia --- fs/xfs/libxfs/xfs_parent.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/fs/xfs/libxfs/xfs_parent.c b/fs/xfs/libxfs/xfs_parent.c index 3509cc4b2175..d6588d0a9286 100644 --- a/fs/xfs/libxfs/xfs_parent.c +++ b/fs/xfs/libxfs/xfs_parent.c @@ -156,6 +156,8 @@ xfs_parent_da_args_init( xfs_ino_t owner, const struct xfs_name *parent_name) { + int local; + args->geo =3D child->i_mount->m_attr_geo; args->whichfork =3D XFS_ATTR_FORK; args->attr_filter =3D XFS_ATTR_PARENT; @@ -168,6 +170,17 @@ xfs_parent_da_args_init( args->value =3D rec; args->valuelen =3D sizeof(struct xfs_parent_rec); xfs_attr_sethash(args); + + /* + * xfs_da_grow_inode_int() subtracts every block it allocates from + * args->total, which is unsigned, so the zero left here by + * kmem_cache_zalloc() wraps to ~0U as soon as the attr fork grows once. + * Derive it the way xfs_attr_set() does instead. A parent pointer's + * value is a struct xfs_parent_rec, so the entry is always local, which + * is what the ASSERT records. + */ + args->total =3D xfs_attr_calc_size(args, &local); + ASSERT(local); } =20 /* Make sure the incore state is ready for a parent pointer query/update. = */ --=20 Javier Tia