From: Sasha Levin <sashal@kernel.org>
To: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Theodore Ts'o <tytso@mit.edu>, Jan Kara <jack@suse.cz>,
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: Fri, 9 Dec 2022 01:53:02 -0500 [thread overview]
Message-ID: <Y5LbTkjORxVhgpKy@sashalap> (raw)
In-Reply-To: <cf8401c8-d9cb-c0be-890b-6aa14d06c1d2@leemhuis.info>
On Fri, Dec 09, 2022 at 07:31:03AM +0100, Thorsten Leemhuis wrote:
>On 09.12.22 07:12, Theodore Ts'o wrote:
>> On Thu, Dec 08, 2022 at 06:16:02PM +0100, Thorsten Leemhuis wrote:
>>>
>>> Maybe I should talk to Greg again to revert backported changes like
>>> 1be97463696c until fixes for them are ready.
>>
>> The fix is in the ext4 git tree, and it's ready to be pushed to Linus
>> when the merge window opens --- presumably, on Sunday.
>
>Thx!
>
>> So it's probably not worth it to revert the backported change, only to
>> reapply immediately afterwards.
>
>Definitely agreed, I was more taking in the general sense (sorry, should
>have been clearer), as it's not the first time some backport exposes
>existing problems that take a while to get analyzed and fixed in
>mainline. Which is just how it is sometimes, hence a revert and a
>reapply of that backport (once the fix is available) in stable/longterm
>sounds appropriate to me to prevent users from running into known problems.
It's a balancing act: reverting a fix would mean that we reintroduce an
issue that was previously fixed back to users. It's not always the right
thing to do, and sometimes we won't.
--
Thanks,
Sasha
prev parent reply other threads:[~2022-12-09 6:53 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
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 [this message]
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=Y5LbTkjORxVhgpKy@sashalap \
--to=sashal@kernel.org \
--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 \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.