From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 59EC2199FAB; Mon, 23 Mar 2026 14:21:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774275706; cv=none; b=UuG/awNB8Jl9YJsWjzVouWXzDyZWmDkG5EW7gzwpRyG6Awv6NxsOusDLbElkrquURBHljsOnVVGQoZDLtCkUfNlb+feElzzj9tw8/35zaFbkv1Ii62VwYj/Wle/jdLQ0lfvPxh/5kd3w2TjGX9/8Sksu4gQ2FK736USG0LenVJY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774275706; c=relaxed/simple; bh=n5Uneys/YL1mNTKSnShkKr8c0sJg9qvr3rqzukXyLts=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NFO80oNxA3HMelJy+NCQ/eDtiw74I8I61FTorBZb1omsmEATwlBQuPWefdLrRtBoL48GjaWMszklX6x0NexzR1SmAOemq6L3s2pJ9rPYqzgpHVeV0C1dZm1ccUhUdkguzk4dX9KWGC/Y8HNBqY/BN99oZnLii8DCvgFWroM0neM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=P77KLm0/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="P77KLm0/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF98BC4CEF7; Mon, 23 Mar 2026 14:21:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1774275706; bh=n5Uneys/YL1mNTKSnShkKr8c0sJg9qvr3rqzukXyLts=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P77KLm0/bfHw3rlq/9Gkvi9GVFPhhCVPcPsMt0J4lSTYXv/KzpK94vCunfDM4d+2l hpX45srEsH8HVRL1T3YI0HyQ8YpIRVwmNf0iewbwCiSurqIVAcwqG8LkVn5hAkSL52 bJv9skPYoPAAA8wP+z/dJi9XboKYRoK8qyKUzP7Y= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Long Li , Carlos Maiolino , Christoph Hellwig , Carlos Maiolino Subject: [PATCH 6.12 189/460] xfs: ensure dquot item is deleted from AIL only after log shutdown Date: Mon, 23 Mar 2026 14:43:05 +0100 Message-ID: <20260323134531.194845851@linuxfoundation.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260323134526.647552166@linuxfoundation.org> References: <20260323134526.647552166@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Long Li commit 186ac39b8a7d3ec7ce9c5dd45e5c2730177f375c upstream. In xfs_qm_dqflush(), when a dquot flush fails due to corruption (the out_abort error path), the original code removed the dquot log item from the AIL before calling xfs_force_shutdown(). This ordering introduces a subtle race condition that can lead to data loss after a crash. The AIL tracks the oldest dirty metadata in the journal. The position of the tail item in the AIL determines the log tail LSN, which is the oldest LSN that must be preserved for crash recovery. When an item is removed from the AIL, the log tail can advance past the LSN of that item. The race window is as follows: if the dquot item happens to be at the tail of the log, removing it from the AIL allows the log tail to advance. If a concurrent log write is sampling the tail LSN at the same time and subsequently writes a complete checkpoint (i.e., one containing a commit record) to disk before the shutdown takes effect, the journal will no longer protect the dquot's last modification. On the next mount, log recovery will not replay the dquot changes, even though they were never written back to disk, resulting in silent data loss. Fix this by calling xfs_force_shutdown() before xfs_trans_ail_delete() in the out_abort path. Once the log is shut down, no new log writes can complete with an updated tail LSN, making it safe to remove the dquot item from the AIL. Cc: stable@vger.kernel.org Fixes: b707fffda6a3 ("xfs: abort consistently on dquot flush failure") Signed-off-by: Long Li Reviewed-by: Carlos Maiolino Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman --- fs/xfs/xfs_dquot.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/fs/xfs/xfs_dquot.c +++ b/fs/xfs/xfs_dquot.c @@ -1472,9 +1472,15 @@ xfs_qm_dqflush( return 0; out_abort: + /* + * Shut down the log before removing the dquot item from the AIL. + * Otherwise, the log tail may advance past this item's LSN while + * log writes are still in progress, making these unflushed changes + * unrecoverable on the next mount. + */ + xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE); dqp->q_flags &= ~XFS_DQFLAG_DIRTY; xfs_trans_ail_delete(lip, 0); - xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE); xfs_dqfunlock(dqp); return error; }