From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 B2B103BED08 for ; Thu, 20 Aug 2026 11:25:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=67.231.153.30 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787225156; cv=none; b=nty2kdKccfHsg0aBNgLmlHpVBdLURoH4HtunfMf1Smw+eMtn2hDySgmX0Ks7sjmQ2gFlHbfYGYvmThmmjBvvNT/vJO6IgXfr/jiRL/nXL0D+2o/Y4SiAi5pQBE0U0OBVMb8UJnG2MaObnywy5lN/vBo0+Htdoi4kKczVlh3kUCw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787225156; c=relaxed/simple; bh=pEeaGQ0Mdt1TA25PSLc7VPAWIjxPHlZzAjXBnPJKvTg=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=uzj5G3L24wBycosGU948O14Nu2g0jgYwntNXXLT3U9Sq1vqnsHMvLGhjB3TqVPMMekYnboYMmza4OeUPKB6J73VmvevV3qTyNUQjG3FlX7w6SQNFoARpXQinZhb830zq2ac2bi2F1A2ccQ41PWzJpqjYKFQw07Brw/qfIYnZPVE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=meta.com; spf=pass smtp.mailfrom=meta.com; dkim=pass (2048-bit key) header.d=meta.com header.i=@meta.com header.b=KagFmqzZ; arc=none smtp.client-ip=67.231.153.30 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=meta.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=meta.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=meta.com header.i=@meta.com header.b="KagFmqzZ" Received: from pps.filterd (m0528005.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67K391bc3937113 for ; Thu, 20 Aug 2026 04:25:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= pps82601-s2048-2026-q3; bh=Kr+K+zjOdEMK9wEKulfes8NAHCfzB3pGDnX9o xPQjJo=; b=KagFmqzZ951XX8MJF6VNCBjnks2ID1/DU+XapiW836v0LX372gJbr b1ixjExCDE6WSnT1a1jK4smxh22Y1/Ne8Pk0B3ZQf584hXCYYqoex27AkVPssae9 VqLqRjjxPcU8bJnvBTkfEqvZvoIkEB5OOMuFCHVqWE9rnyuTbTnBb6TAQNk32jcj Z7G6hVl9fIAiJbtODijskdpUlVbE75pux+R7sLK0RaYGxxZ/eRHRR8BQ70XZBW1s dZCFKTkuij31TekhmRHStEm6/lZzp0Nwd6PmDajkqhIyAHmMb5UB+6Z6ux7cPekP hyygvMtl36VFutt1WNxZNcYcuV18SPHDA== Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 4g4yfmvuu3-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 20 Aug 2026 04:25:49 -0700 (PDT) Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-52769fc3f2eso29621301cf.0 for ; Thu, 20 Aug 2026 04:25:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787225148; x=1787829948; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Kr+K+zjOdEMK9wEKulfes8NAHCfzB3pGDnX9oxPQjJo=; b=CRrMQRMPklz7WD8ZJC1dL+ZTcnOQM/ij5F8aYriLg5uBo6M6SAL3bnb/iMwOLPPrD2 wee08aDv36No9q43L/zRcQO7K//lfCXlY1lQbg3LwiuaWMuTCFqSKH42EZe+A1qGqZM6 R5PbpNTSV4K9tqp9uk56kTHXbXMbJBt0IGcwh7YLtCVa/POfpykfgZKnx85pVSI5P+T+ UR4RgcDUwBrYfjfKOkCrNeBTFM1ezwvRnwfEdG1XYdnuzTGWusmxzvPTwGGLiOD5/RP4 1GYayNYj0m+knO5GQ1wVeESOEW2J9MwQ5xRB1zylvVWC1nrdlo4oa/hakpvx8E+XymiZ jkWg== X-Forwarded-Encrypted: i=1; AHgh+RoLiIzc/GoWolX2Y6AD7Pm9rMlqv7aZYrYR52sVFMDhrqSV31RqshleyNp8NI1QEczzQ94nmlcabjRtxMM=@vger.kernel.org X-Gm-Message-State: AOJu0YxGQPowe2vP4wKtsDXLGdFD0QOyI8IUAmHoZTKOYG6geXxaEghU VQrKZzmS9h2+RndlyS13UnSYYZKEfOncXZZclHL1xBNhMkfoc3OgB6+7ttVhKC+6pXCQgeONKSu fefn4qzcE90/iRW/eK63IDMhVc15nMUUXMhBN0tBPQKEg/Td3IK2+Dyon6z0vimhR X-Gm-Gg: AR+sD11SRwBvZzqAcufCnoGGYHNwzlIYgZ4jyITHIjwZbMHsh/4dScbktMZF7lVj8gH 1mcHeHSYPMPo2VL5RmSNrt5pW/NMWisrLHdmGw071PeoloFLwGhHMkz0MCgLZ3bd0HiWrnmrQhp sP1IHF/zyHE+jsRREqu4Gx2lZ0UQPpNK/l/zzsiG6IB8s0421NYAj9+yuHxWEHCNn/dkAoz+hxI RDCLHBYoOmcVtD94c09Sp05hrzlTxvy0WeMJ0z0arJWU3QxxPHY+zVLBUlFGqfEnCfMWYJkohr3 E7tfsn8qMcPmBnPON5a/KgxTNJJCBoe2bl/Lo4hJW3MVnrxYJzBOJRWGY+vk576F68ojg3RcaOq m X-Received: by 2002:a05:622a:58cd:b0:51a:8696:cb38 with SMTP id d75a77b69052e-52dd57853damr115785031cf.7.1787225148394; Thu, 20 Aug 2026 04:25:48 -0700 (PDT) X-Received: by 2002:a05:622a:58cd:b0:51a:8696:cb38 with SMTP id d75a77b69052e-52dd57853damr115784341cf.7.1787225147838; Thu, 20 Aug 2026 04:25:47 -0700 (PDT) Received: from [192.168.77.173] ([68.20.15.154]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-52dd872f61esm29031451cf.23.2026.08.20.04.25.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Aug 2026 04:25:47 -0700 (PDT) Message-ID: <3a7777fb1f0678c88c2365a6a476167b5abc4e9d.camel@meta.com> Subject: Re: [PATCH] btrfs: abort transaction before releasing tree_log_mutex on commit failure From: "jlayton@meta.com" To: Leo Martins , linux-btrfs@vger.kernel.org, kernel-team@fb.com Cc: Chris Mason , David Sterba , Filipe Manana , Johannes Thumshirn , Josef Bacik , Qu Wenruo , linux-kernel@vger.kernel.org, stable@vger.kernel.org Date: Thu, 20 Aug 2026 07:25:46 -0400 In-Reply-To: <698c480ec13cd6e74c2175924f614b7e324e6cc3.1787099421.git.loemra.dev@gmail.com> References: <698c480ec13cd6e74c2175924f614b7e324e6cc3.1787099421.git.loemra.dev@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.2 (3.60.2-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Authority-Analysis: v=2.4 cv=NLblPU6g c=1 sm=1 tr=0 ts=6a86e43d cx=c_pps a=WeENfcodrlLV9YRTxbY/uA==:117 a=I8GJ1mTG6nUeI1lZk6893w==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=7j0FZ4iXMVMA:10 a=VkNPw1HP01LnGYTKEx00:22 a=7x6HtfJdh03M6CCDgxCd:22 a=jCddH8ec0KUNCymVuxII:22 a=VwQbUJbxAAAA:8 a=pGLkceISAAAA:8 a=VabnemYjAAAA:8 a=5xnzj68laMxwpfVuNd8A:9 a=QEXdDO2ut3YA:10 a=kacYvNCVWA4VmyqE58fU:22 a=gKebqoRLp9LExxC7YDUY:22 X-Proofpoint-ORIG-GUID: lVw4OUAcMnohCa-lCHglIjNWdFsoghIv X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODIwMDA4NCBTYWx0ZWRfXw/HXNIgKPisS 8svXNye5CuuSDuxogFVqFZOvl39BKPjB1AOhU9Lv4D6F1OzH0lwH2IJM1OH/rrUvQR+KTpGhxlh G9SL3vk4lF9VsI3/xsiGWriIuespiaCaPG//J+2npcF6s5qhbw/nTXnQhiZxLBjfYZQM0/O84hE oUiVXIs7LhsyRGiQLamnpAgxMuMQ7dEq+hxckdh2YKJ4awcq2emyyIWKXePjaOQBiW2v2j7gL6B blIwyvyyWmqge1WzA0l+prPbDKtnULNdHakT5izgHaKjb6/U/yjX4+kopZau+8OmLzw5UqSi1Y+ GJE0d99AaMdIQT9MVTWN0DtszGpGmFEvjpfy4DGGBgep+x1RmN+z9E9Y823QrdPClDC4ys2sEuY vIt1NEwmZFyv8x25B36WHMDYVi1RFf2VxDXqZw7lqHQ91jibMdmM21/S3EOTJ2q+TNYKCYMHvlG dMC6LkB2J3ruJLLY3Hg== X-Proofpoint-Spam-Info: AW1haW4tMjYwODIwMDA4NCBTYWx0ZWRfX+suFaQGpiScV vlWd8UFxIngi0n+FmdOdkHt5qVTj2eKHtnXPZEdCDnQ6dI8M7Z4Z14JJ1AviPUaBrkHM2b/VxX4 8eWY5jdMwbUDYFpSEv63hgZm89+SmoQ= X-Proofpoint-GUID: lVw4OUAcMnohCa-lCHglIjNWdFsoghIv X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-19_06,2026-08-19_02,2025-10-01_01 On Tue, 2026-08-18 at 17:40 -0700, Leo Martins wrote: > When transaction metadata writeout fails in btrfs_commit_transaction(), > the current code only logs the error, drops tree_log_mutex and then goes > through cleanup_transaction(), which aborts the transaction and records > the fs error. >=20 > That is too late for the tree log side. A log sync can already be > waiting on tree_log_mutex, because the committing transaction is moved > to TRANS_STATE_UNBLOCKED while that mutex is held, which lets fsyncs > join the next transaction and queue up in btrfs_sync_log(). Once the > failed commit drops tree_log_mutex, such a log sync acquires it, sees > BTRFS_FS_ERROR() still clear, and writes super_for_commit. That > superblock holds the roots prepared for the transaction that has just > failed to write out its metadata, so it can point at tree blocks that > never reached the disk, and the next mount fails with a parent transid > mismatch. >=20 > Commit 165ea85f1483 ("btrfs: do not write supers if we have an fs > error") fixed this class of problem by making btrfs_sync_log() check for > an fs error right after taking tree_log_mutex. That check only works if > the commit path publishes the fs error before it releases the same > mutex, and commit 68d4ece9c30e ("btrfs: don't call > btrfs_handle_fs_error() in btrfs_commit_transaction()") removed the only > thing that did so. >=20 > Restore the ordering by aborting the transaction while tree_log_mutex is > still held. We have a transaction handle here, so this does not need to > bring back the btrfs_handle_fs_error() call: __btrfs_abort_transaction() > records the fs error itself, which is all btrfs_sync_log() looks at, and > the error message put in its place is kept. >=20 > This is what commit 3810ab40afa5 ("btrfs: abort transaction on error in > write_all_supers()") already does for the next call in this function. >=20 > This is reproducible on an unmodified kernel by failing the first > couple of bios of a transaction commit with fail_make_request while a > concurrent fsync workload keeps log syncs queued on tree_log_mutex. >=20 > Fixes: 68d4ece9c30e ("btrfs: don't call btrfs_handle_fs_error() in btrfs_= commit_transaction()") > Cc: stable@vger.kernel.org # 7.0+ > Signed-off-by: Leo Martins > --- > fs/btrfs/transaction.c | 6 ++++++ > 1 file changed, 6 insertions(+) >=20 > diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c > index 13a7e5f4e08c..ed850bf0546a 100644 > --- a/fs/btrfs/transaction.c > +++ b/fs/btrfs/transaction.c > @@ -2583,6 +2583,12 @@ int btrfs_commit_transaction(struct btrfs_trans_ha= ndle *trans) > ret =3D btrfs_write_and_wait_transaction(trans); > if (unlikely(ret)) { > btrfs_err(fs_info, "error while writing out transaction: %pe", ERR_PTR= (ret)); > + /* > + * Abort before releasing tree_log_mutex, so a log sync waiting > + * on it sees the fs error and skips writing super_for_commit > + * for this failed transaction. See btrfs_sync_log(). > + */ > + btrfs_abort_transaction(trans, ret); > mutex_unlock(&fs_info->tree_log_mutex); > goto scrub_continue; > } Reviewed-by: jlayton@meta.com