From: Lukas Czerner <lczerner@redhat.com>
To: linux-ext4@vger.kernel.org
Cc: Jan Kara <jack@suse.cz>
Subject: jbd2: can b_transaction be NULL in refile_buffer ?
Date: Thu, 11 Jun 2020 10:34:17 +0200 [thread overview]
Message-ID: <20200611083417.4akdykeubd7kfuuh@work> (raw)
Hi,
I am tracking a rare and very hard to reproduce bug that ends up hittng
J_ASSERT_JH(jh, jh->b_transaction == NULL)
in __journal_remove_journal_head(). In fact we can get there with
b_next_transaction set and b_jlist == BJ_Forget so it's clear that we
should not have dropped the last JH reference at that point.
Most of the time that I've seen we get there from
__jbd2_journal_remove_checkpoint() called from
jbd2_journal_commit_transaction().
The locking in and around grabbing and putting the journal head
reference (b_jcount) looks solid as well as the use of j_list_lock. But
I have noticed a problem in logic of __jbd2_journal_refile_buffer().
The idea is that b_next_transaction will inherit the reference from
b_transaction so that we do not need to grab a new reference of
journal_head. However this will only be true if b_transaction is set.
But if it is indeed NULL, then we will do
WRITE_ONCE(jh->b_transaction, jh->b_next_transaction);
and __jbd2_journal_file_buffer() will not grab the jh reference. AFAICT
the b_next_transaction is not holding it's own jh reference. This will
result in b_transaction _not_ holding it's own jh reference and we will
be able to drop the last jh reference at unexpected places - hence we can
hit the asserts in __journal_remove_journal_head().
However I am not really sure if it is indeed possible to get into
__jbd2_journal_refile_buffer() with b_transaction == NULL and
b_next_transaction set. Jan do you have any idea if that's possible and
what would be the circumstances to lead us there ?
Regardless I still think this is a bug in the logic and we should either
make sure that b_transaction is _not_ NULL in
__jbd2_journal_refile_buffer(), or let __jbd2_journal_file_buffer() grab
the jh reference if b_transaction was indeen NULL. How about something
like the following untested patch ?
Thanks!
-Lukas
--
diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index e91aad3637a2..55e5cb6b4bb5 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -2498,7 +2498,7 @@ void __jbd2_journal_file_buffer(struct journal_head *jh,
__jbd2_journal_temp_unlink_buffer(jh);
else
jbd2_journal_grab_journal_head(bh);
- jh->b_transaction = transaction;
+ WRITE_ONCE(jh->b_transaction, transaction);
switch (jlist) {
case BJ_None:
@@ -2577,15 +2577,14 @@ bool __jbd2_journal_refile_buffer(struct journal_head *jh)
* our jh reference and thus __jbd2_journal_file_buffer() must not
* take a new one.
*/
- WRITE_ONCE(jh->b_transaction, jh->b_next_transaction);
- WRITE_ONCE(jh->b_next_transaction, NULL);
if (buffer_freed(bh))
jlist = BJ_Forget;
else if (jh->b_modified)
jlist = BJ_Metadata;
else
jlist = BJ_Reserved;
- __jbd2_journal_file_buffer(jh, jh->b_transaction, jlist);
+ __jbd2_journal_file_buffer(jh, jh->b_next_transaction, jlist);
+ WRITE_ONCE(jh->b_next_transaction, NULL);
J_ASSERT_JH(jh, jh->b_transaction->t_state == T_RUNNING);
if (was_dirty)
(END)
next reply other threads:[~2020-06-11 8:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 8:34 Lukas Czerner [this message]
2020-06-11 10:37 ` jbd2: can b_transaction be NULL in refile_buffer ? Jan Kara
2020-06-11 10:50 ` Lukas Czerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200611083417.4akdykeubd7kfuuh@work \
--to=lczerner@redhat.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox