From: Jan Kara <jack@suse.cz>
To: Zhang Yi <yi.zhang@huawei.com>
Cc: Jan Kara <jack@suse.cz>,
linux-ext4@vger.kernel.org,
Alexander Coffin <alex.coffin@maticrobots.com>,
stable@vger.kernel.org, Ted Tso <tytso@mit.edu>,
chengzhihao1@huawei.com
Subject: Re: [PATCH v2 3/4] jbd2: Avoid infinite transaction commit loop
Date: Wed, 26 Jun 2024 13:22:54 +0200 [thread overview]
Message-ID: <20240626112254.cu4un6lua2glkfkn@quack3> (raw)
In-Reply-To: <2d49e3de-d7e7-2fd1-0b7a-9a3f9e04cd4d@huawei.com>
On Wed 26-06-24 15:38:42, Zhang Yi wrote:
> On 2024/6/25 1:01, Jan Kara wrote:
> > Commit 9f356e5a4f12 ("jbd2: Account descriptor blocks into
> > t_outstanding_credits") started to account descriptor blocks into
> > transactions outstanding credits. However it didn't appropriately
> > decrease the maximum amount of credits available to userspace. Thus if
> > the filesystem requests a transaction smaller than
> > j_max_transaction_buffers but large enough that when descriptor blocks
> > are added the size exceeds j_max_transaction_buffers, we confuse
> > add_transaction_credits() into thinking previous handles have grown the
> > transaction too much and enter infinite journal commit loop in
> > start_this_handle() -> add_transaction_credits() trying to create
> > transaction with enough credits available.
>
> I understand that the incorrect max transaction limit in
> start_this_handle() could lead to infinite loop in
> start_this_handle()-> add_transaction_credits() with large enough
> userspace credits (from j_max_transaction_buffers - overheads to
> j_max_transaction_buffers), but I don't get how could it lead to ran
> out of space in the journal commit traction? IIUC, below codes in
> add_transaction_credits() could make sure that we have enough space
> when committing traction:
>
> static int add_transaction_credits()
> {
> ...
> if (jbd2_log_space_left(journal) < journal->j_max_transaction_buffers) {
> ...
> return 1;
> ...
> }
> ...
> }
>
> I can't open and download the image Alexander gave, so I can't get to
> the bottom of this issue, please let me know what happened with
> jbd2_journal_next_log_block().
Sure. So what was exactly happening is a loop like this:
start_this_handle()
blocks = 252 (handle->h_total_credits)
- starts a new transaction
- t_outstanding_credits set to 6 to account for the commit block and
descriptor blocks
add_transaction_credits(journal, 252, 0)
needed = atomic_add_return(252, &t->t_outstanding_credits);
if (needed > journal->j_max_transaction_buffers) {
/* Yes, this is exceeded due to descriptor blocks being in
* t_outstanding_credits */
...
wait_transaction_locked(journal);
- this commits an empty transaction - contains only the commit
block
return 1
goto repeat
So we commit single block transactions in a loop until we exhaust all the
journal space. The condition in add_transaction_credits() whether there's
enough space in the journal is never reached so we don't ever push the
journal tail to make space in the journal.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2024-06-26 11:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240624165406.12784-1-jack@suse.cz>
2024-06-24 17:01 ` [PATCH v2 1/4] jbd2: Make jbd2_journal_get_max_txn_bufs() internal Jan Kara
2024-06-27 6:47 ` Zhang Yi
2024-07-11 2:35 ` Theodore Ts'o
2024-06-24 17:01 ` [PATCH v2 2/4] jbd2: Precompute number of transaction descriptor blocks Jan Kara
2024-06-25 9:31 ` Kemeng Shi
2024-06-25 11:07 ` Jan Kara
2024-06-25 12:02 ` Kemeng Shi
2024-06-27 7:06 ` Zhang Yi
2024-06-24 17:01 ` [PATCH v2 3/4] jbd2: Avoid infinite transaction commit loop Jan Kara
2024-06-26 7:38 ` Zhang Yi
2024-06-26 11:22 ` Jan Kara [this message]
2024-06-26 13:24 ` Zhang Yi
2024-06-26 14:55 ` Jan Kara
2024-06-27 6:43 ` Zhang Yi
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=20240626112254.cu4un6lua2glkfkn@quack3 \
--to=jack@suse.cz \
--cc=alex.coffin@maticrobots.com \
--cc=chengzhihao1@huawei.com \
--cc=linux-ext4@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=yi.zhang@huawei.com \
/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