From: <gregkh@linuxfoundation.org>
To: dave@stgolabs.net,gregkh@linuxfoundation.org,jack@suse.cz,kdevops@lists.linux.dev,mcgrof@kernel.org,stable@kernel.org,tytso@mit.edu,yi.zhang@huawei.com
Cc: <stable-commits@vger.kernel.org>
Subject: Patch "ext4: fix calculation of credits for extent tree modification" has been added to the 5.15-stable tree
Date: Fri, 20 Jun 2025 11:02:24 +0200 [thread overview]
Message-ID: <2025062024-prankish-ending-d24f@gregkh> (raw)
This is a note to let you know that I've just added the patch titled
ext4: fix calculation of credits for extent tree modification
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ext4-fix-calculation-of-credits-for-extent-tree-modification.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From 32a93f5bc9b9812fc710f43a4d8a6830f91e4988 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Tue, 29 Apr 2025 19:55:36 +0200
Subject: ext4: fix calculation of credits for extent tree modification
From: Jan Kara <jack@suse.cz>
commit 32a93f5bc9b9812fc710f43a4d8a6830f91e4988 upstream.
Luis and David are reporting that after running generic/750 test for 90+
hours on 2k ext4 filesystem, they are able to trigger a warning in
jbd2_journal_dirty_metadata() complaining that there are not enough
credits in the running transaction started in ext4_do_writepages().
Indeed the code in ext4_do_writepages() is racy and the extent tree can
change between the time we compute credits necessary for extent tree
computation and the time we actually modify the extent tree. Thus it may
happen that the number of credits actually needed is higher. Modify
ext4_ext_index_trans_blocks() to count with the worst case of maximum
tree depth. This can reduce the possible number of writers that can
operate in the system in parallel (because the credit estimates now won't
fit in one transaction) but for reasonably sized journals this shouldn't
really be an issue. So just go with a safe and simple fix.
Link: https://lore.kernel.org/all/20250415013641.f2ppw6wov4kn4wq2@offworld
Reported-by: Davidlohr Bueso <dave@stgolabs.net>
Reported-by: Luis Chamberlain <mcgrof@kernel.org>
Tested-by: kdevops@lists.linux.dev
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Link: https://patch.msgid.link/20250429175535.23125-2-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/extents.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -2372,18 +2372,19 @@ int ext4_ext_calc_credits_for_single_ext
int ext4_ext_index_trans_blocks(struct inode *inode, int extents)
{
int index;
- int depth;
/* If we are converting the inline data, only one is needed here. */
if (ext4_has_inline_data(inode))
return 1;
- depth = ext_depth(inode);
-
+ /*
+ * Extent tree can change between the time we estimate credits and
+ * the time we actually modify the tree. Assume the worst case.
+ */
if (extents <= 1)
- index = depth * 2;
+ index = EXT4_MAX_EXTENT_DEPTH * 2;
else
- index = depth * 3;
+ index = EXT4_MAX_EXTENT_DEPTH * 3;
return index;
}
Patches currently in stable-queue which might be from jack@suse.cz are
queue-5.15/ext4-inline-fix-len-overflow-in-ext4_prepare_inline_data.patch
queue-5.15/ext4-fix-calculation-of-credits-for-extent-tree-modification.patch
queue-5.15/jbd2-fix-data-race-and-null-ptr-deref-in-jbd2_journal_dirty_metadata.patch
queue-5.15/ext4-ensure-i_size-is-smaller-than-maxbytes.patch
queue-5.15/ocfs2-fix-possible-memory-leak-in-ocfs2_finish_quota.patch
queue-5.15/ext4-factor-out-ext4_get_maxbytes.patch
reply other threads:[~2025-06-20 9:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=2025062024-prankish-ending-d24f@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=dave@stgolabs.net \
--cc=jack@suse.cz \
--cc=kdevops@lists.linux.dev \
--cc=mcgrof@kernel.org \
--cc=stable-commits@vger.kernel.org \
--cc=stable@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