From: "Theodore Ts'o" <tytso@mit.edu>
To: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>,
Jan Kara <jack@suse.cz>,
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 00:55:55 -0500 [thread overview]
Message-ID: <Y5F8ayz4gEtKn0LF@mit.edu> (raw)
In-Reply-To: <9c414060-989d-55bb-9a7b-0f33bf103c4f@leemhuis.info>
On Mon, Dec 05, 2022 at 04:41:49PM +0100, Thorsten Leemhuis wrote:
>
> Jan's patch to fix the regression is now our 12 days out and afaics
> didn't make any progress (or did I miss something?). Is there are reason
> why or did it simply fall through the cracks? Just asking, because it
> would be good to finally get this resolved.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
This patch showed up right before the Thanksgiving holiday, and (b) it
just missed Q/A cutoff for the the ext4 bugfix pull request which I
sent to Linus right before I went on my Thanksgiving break.
Since Thanksgiving, I've been busy with the realities of corporate
life --- end of year performance evaluations, preparing for 2023
roadmap reviews with management, etc. So the next pull request I was
planning to send to Linus is when the merge window opens, and I'm
currently processing patches and running Q/A to be ready for the
opening of that merge window.
One thing which is completely unclear to me is how this relates to the
claimed regression. I understand that Jeremi and Thilo have asserted
that the hang goes away if a backport commit 51ae846cff5 ("ext4: fix
warning in ext4_iomap_begin as race between bmap and write") is not in
their 5.15 product tree.
However, the stack traces point to a problem in the extended attribute
code, which has nothing to do with ext4_bmap(), and commit 51ae846cff5
only changes the ext4's bmap function --- which these days gets used
for the FIBMAP ioctl and very little else.
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. ?!?
So at this point, I have no idea whether or not this is a regression
or not, but we'll get the fix to Linus soon.
Cheers,
- Ted
next prev parent reply other threads:[~2022-12-08 5:56 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 [this message]
2022-12-08 9:15 ` Jan Kara
2022-12-08 15:20 ` Jeremi Piotrowski
2022-12-08 15:39 ` Theodore Ts'o
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=Y5F8ayz4gEtKn0LF@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