From: Filipe Manana <fdmanana@kernel.org>
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: dsterba@suse.cz, Filipe Manana <fdmanana@suse.com>,
David Sterba <dsterba@suse.com>,
stable@vger.kernel.org, patches@lists.linux.dev,
Josef Bacik <josef@toxicpanda.com>,
Sasha Levin <sashal@kernel.org>, Chris Mason <clm@fb.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 6.7 001/162] btrfs: fix deadlock with fiemap and extent locking
Date: Wed, 13 Mar 2024 13:47:47 +0000 [thread overview]
Message-ID: <CAL3q7H6jVfg2GkhEsJk64+TdRq5CdapfSfSgXvqoCa4U6zXbKg@mail.gmail.com> (raw)
In-Reply-To: <5f7b720c-3516-42b2-826c-68fb5ba18353@leemhuis.info>
On Wed, Mar 13, 2024 at 1:42 PM Linux regression tracking (Thorsten
Leemhuis) <regressions@leemhuis.info> wrote:
>
> On 11.03.24 21:06, Filipe Manana wrote:
> > On Mon, Mar 11, 2024 at 7:23 PM Linux regression tracking (Thorsten
> > Leemhuis) <regressions@leemhuis.info> wrote:
> >>
> >> On 11.03.24 19:41, David Sterba wrote:
> >>> On Mon, Mar 11, 2024 at 10:15:31AM +0100, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>>> On 06.03.24 13:39, Filipe Manana wrote:
> >>>>> On Mon, Mar 4, 2024 at 9:26 PM Greg Kroah-Hartman
> >>>>> <gregkh@linuxfoundation.org> wrote:
> >>>>>>
> >>>>>> 6.7-stable review patch. If anyone has any objections, please let me know.
> >>>>> It would be better to delay the backport of this patch (and the
> >>>>> followup fix) to any stable release, because it introduced another
> >>>>> regression for which there is a reviewed fix but it's not yet in
> >>>>> Linus' tree:
> >>>>> https://lore.kernel.org/linux-btrfs/cover.1709202499.git.fdmanana@suse.com/
> >>>> Those two missed 6.8 afaics. Will those be heading to mainline any time
> >>>> soon?
> >>> Yes, in the 6.9 pull request.
> >> Great!
> >>
> >>>> And how fast afterwards will it be wise to backport them to 6.8?
> >>>> Will anyone ask Greg for that when the time has come?
> >>> The commits have stable tags and will be processed in the usual way.
> >
> >> I'm missing something. The first change from Filipe's series linked
> >> above has a fixes tag, but no stable tag afaics:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git/commit/?h=for-6.9&id=978b63f7464abcfd364a6c95f734282c50f3decf
> >
> > It has no stable tag because when I sent the patch there was yet no
> > kernel release with the buggy commit
>
> Obviously, no need to explain, the discussion got unintentionally
> sideways after David mistakenly said "The commits have stable tags
> [...]". Happens, no worries.
>
> >> So there is no guarantee that Greg will pick it up; and I assume if he
> >> does he only will do so after -rc1 (or later, if the CVE stuff continues
> >> to keep him busy).
> >
> > Don't worry, we are paying attention to that and we'll remind Greg if necessary.
>
> Thx. But well, for the record: I would really have liked if you or David
> would simply have just answered my earlier "And how fast afterwards will
> it be wise to backport them to 6.8?" question instead of avoiding it.
If I avoided that question it's because I can't give an answer to it.
David is the maintainer who picks patches for Linus and does the pull requests.
So the "how fast" depends on him and then how fast Linus merges and
then how fast Greg and the stable people pick it.
> Just knowing a rough estimate would have helped. And I guess Greg might
> have liked to know the answer, too. But whatever.
>
> Side note: I'm here to "worry". It's not that I don't trust you or would
> ask Greg behind your back to pick the patches up. It's just that we are
> all humans[1]. And regression tracking is here to help with the flaws
> humans have: they miss things, they suddenly need to go to hospitals for
> a while, they become preoccupied with solving the next complicated and
> big bug of the month, or just forget something they wanted to do because
> something unexpected happens, like aliens landing in a unidentified
> flying object. And from all the regressions I see that are not handled
> well and the feedback I got it seems doing this work seems to be worth it.
>
> Ciao, Thorsten
>
> [1] at least I think so...
> https://en.wikipedia.org/wiki/On_the_Internet,_nobody_knows_you%27re_a_dog
> :-D
>
next prev parent reply other threads:[~2024-03-13 13:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240304211551.833500257@linuxfoundation.org>
[not found] ` <20240304211551.880347593@linuxfoundation.org>
[not found] ` <CAKisOQGCiJUUc62ptxp08LkR88T5t1swcBPYi84y2fLP6Tag7g@mail.gmail.com>
2024-03-11 9:15 ` [PATCH 6.7 001/162] btrfs: fix deadlock with fiemap and extent locking Linux regression tracking (Thorsten Leemhuis)
2024-03-11 18:41 ` David Sterba
2024-03-11 19:23 ` Linux regression tracking (Thorsten Leemhuis)
2024-03-11 20:06 ` Filipe Manana
2024-03-13 13:42 ` Linux regression tracking (Thorsten Leemhuis)
2024-03-13 13:47 ` Filipe Manana [this message]
2024-03-12 16:41 ` David Sterba
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=CAL3q7H6jVfg2GkhEsJk64+TdRq5CdapfSfSgXvqoCa4U6zXbKg@mail.gmail.com \
--to=fdmanana@kernel.org \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=fdmanana@suse.com \
--cc=gregkh@linuxfoundation.org \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=regressions@lists.linux.dev \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).