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 761902080C0; Tue, 21 Oct 2025 20:00:24 +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=1761076824; cv=none; b=sp2BcrPbXp50PFZDfWbQNK0b0u+fdmUM2htIdkaWhUM+h7d055MANQ7FPMPMS89xCZCkrcsqDKn+xrfRSgZUnP1cd2i/m5XFxlEu32RAARRkxmNs5F1OmBR8qPMKAZ1pze3cGuhGWqUJAfksAn7l/pFRvU5EPOXzM+73Vm4gJyw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761076824; c=relaxed/simple; bh=m4FN5xZ+03ZJabrncKLM/m1sureZOoGipambBm5tC0w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ibTkaPUKVN1JsA8VdGJV+JY+2l1HtHmE7nJD97649xwEsa8Qm9maM0b1lwtzGebt5iOMYOuQGPL/NqzonDFge6lB2BZyj+ewLEFBaRacCYfnq+4Cr/YaPV3ee4xbNQI9S0KSkEwySPxCZBFmFwRB7dRFf9lHOlW05wTpyi10VvM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=SqAOo/gq; 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="SqAOo/gq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02542C4CEF1; Tue, 21 Oct 2025 20:00:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761076824; bh=m4FN5xZ+03ZJabrncKLM/m1sureZOoGipambBm5tC0w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SqAOo/gqdytuNGqg6sbKo3CeX8Rd22R05ePs0XwqqNZB0Xt0rqxJ/caKLC37QP52f U9RpuD7Q93pX3TN1/QYqJAmPu1u0aK27Oi8llzy4AMw5zbDBNF/FHNKYdPU4988zxW dfmawAUurRUemZD9jVFUd1JoiY2XOPGJMHweL/zg= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, stable@kernel.org, Jan Kara , Zhang Yi , Theodore Tso Subject: [PATCH 6.12 008/136] jbd2: ensure that all ongoing I/O complete before freeing blocks Date: Tue, 21 Oct 2025 21:49:56 +0200 Message-ID: <20251021195036.162934501@linuxfoundation.org> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20251021195035.953989698@linuxfoundation.org> References: <20251021195035.953989698@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev 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: Zhang Yi commit 3c652c3a71de1d30d72dc82c3bead8deb48eb749 upstream. When releasing file system metadata blocks in jbd2_journal_forget(), if this buffer has not yet been checkpointed, it may have already been written back, currently be in the process of being written back, or has not yet written back. jbd2_journal_forget() calls jbd2_journal_try_remove_checkpoint() to check the buffer's status and add it to the current transaction if it has not been written back. This buffer can only be reallocated after the transaction is committed. jbd2_journal_try_remove_checkpoint() attempts to lock the buffer and check its dirty status while holding the buffer lock. If the buffer has already been written back, everything proceeds normally. However, there are two issues. First, the function returns immediately if the buffer is locked by the write-back process. It does not wait for the write-back to complete. Consequently, until the current transaction is committed and the block is reallocated, there is no guarantee that the I/O will complete. This means that ongoing I/O could write stale metadata to the newly allocated block, potentially corrupting data. Second, the function unlocks the buffer as soon as it detects that the buffer is still dirty. If a concurrent write-back occurs immediately after this unlocking and before clear_buffer_dirty() is called in jbd2_journal_forget(), data corruption can theoretically still occur. Although these two issues are unlikely to occur in practice since the undergoing metadata writeback I/O does not take this long to complete, it's better to explicitly ensure that all ongoing I/O operations are completed. Fixes: 597599268e3b ("jbd2: discard dirty data when forgetting an un-journalled buffer") Cc: stable@kernel.org Suggested-by: Jan Kara Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Message-ID: <20250916093337.3161016-2-yi.zhang@huaweicloud.com> Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- fs/jbd2/transaction.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/fs/jbd2/transaction.c +++ b/fs/jbd2/transaction.c @@ -1663,6 +1663,7 @@ int jbd2_journal_forget(handle_t *handle int drop_reserve = 0; int err = 0; int was_modified = 0; + int wait_for_writeback = 0; if (is_handle_aborted(handle)) return -EROFS; @@ -1786,18 +1787,22 @@ int jbd2_journal_forget(handle_t *handle } /* - * The buffer is still not written to disk, we should - * attach this buffer to current transaction so that the - * buffer can be checkpointed only after the current - * transaction commits. + * The buffer has not yet been written to disk. We should + * either clear the buffer or ensure that the ongoing I/O + * is completed, and attach this buffer to current + * transaction so that the buffer can be checkpointed only + * after the current transaction commits. */ clear_buffer_dirty(bh); + wait_for_writeback = 1; __jbd2_journal_file_buffer(jh, transaction, BJ_Forget); spin_unlock(&journal->j_list_lock); } drop: __brelse(bh); spin_unlock(&jh->b_state_lock); + if (wait_for_writeback) + wait_on_buffer(bh); jbd2_journal_put_journal_head(jh); if (drop_reserve) { /* no need to reserve log space for this block -bzzz */