From: "Theodore Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>,
Andreas Dilger <adilger.kernel@dilger.ca>,
linux-ext4@vger.kernel.org, stable@vger.kernel.org,
Thilo Fromm <t-lo@linux.microsoft.com>,
Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>,
Andreas Gruenbacher <agruenba@redhat.com>
Subject: Re: [PATCH] ext4: Fix deadlock due to mbcache entry corruption
Date: Thu, 8 Dec 2022 10:39:51 -0500 [thread overview]
Message-ID: <Y5IFR4K9hO8ax1Y0@mit.edu> (raw)
In-Reply-To: <20221208091523.t6ka6tqtclcxnsrp@quack3>
On Thu, Dec 08, 2022 at 10:15:23AM +0100, Jan Kara wrote:
> > Furthermore, the fix which Jan provided, and which apparently fixes
> > the user's problem, (a) doesn't touch the ext4_bmap function, and (b)
> > has a fixes tag for the patch:
> >
> > Fixes: 6048c64b2609 ("mbcache: add reusable flag to cache entries")
> >
> > ... which is a commit which dates back to 2016, and the v4.6 kernel. ?!?
>
> Yes. AFAICT the bitfield race in mbcache was introduced in this commit but
> somehow ext4 was using mbcache in a way that wasn't tripping the race.
> After 65f8b80053 ("ext4: fix race when reusing xattr blocks"), the race
> became much more likely and users started to notice...
Ah, OK. And 65f8b80053 landed in 6.0, so while the bug may have been
around for much longer, this change made it much more likely that
folks would notice. That's the missing piece and why Microsoft
started noticing this in their "Flatcar" container kernel.
So I'll update the commit description so that this is more clear, and
then I can figure out how to tell the regression-bot that the
regression should be tracked using commit 65f8b80053 instead of
51ae846cff5 ("ext4: fix warning in ext4_iomap_begin as race between
bmap and write").
Cheers, and thanks for the clarification,
- Ted
next prev parent reply other threads:[~2022-12-08 15:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 19:39 [PATCH] ext4: Fix deadlock due to mbcache entry corruption Jan Kara
2022-12-01 15:10 ` Jeremi Piotrowski
2022-12-05 15:41 ` Thorsten Leemhuis
2022-12-06 1:52 ` Andreas Dilger
2022-12-08 5:55 ` Theodore Ts'o
2022-12-08 9:15 ` Jan Kara
2022-12-08 15:20 ` Jeremi Piotrowski
2022-12-08 15:39 ` Theodore Ts'o [this message]
2022-12-08 17:16 ` Thorsten Leemhuis
2022-12-09 6:12 ` Theodore Ts'o
2022-12-09 6:31 ` Thorsten Leemhuis
2022-12-09 6:53 ` Sasha Levin
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=Y5IFR4K9hO8ax1Y0@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=agruenba@redhat.com \
--cc=jack@suse.cz \
--cc=jpiotrowski@linux.microsoft.com \
--cc=linux-ext4@vger.kernel.org \
--cc=regressions@leemhuis.info \
--cc=stable@vger.kernel.org \
--cc=t-lo@linux.microsoft.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