public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Tejun Heo <tj@kernel.org>
Cc: Linux regressions mailing list <regressions@lists.linux.dev>,
	Sasha Levin <sashal@kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Hibernate stuck after recent kernel/workqueue.c changes in Stable 6.6.23
Date: Wed, 3 Apr 2024 18:10:39 +0200	[thread overview]
Message-ID: <2024040319-doorbell-ecosystem-7d31@gregkh> (raw)
In-Reply-To: <Zg10Keik4KORjXMh@slm.duckdns.org>

On Wed, Apr 03, 2024 at 05:22:17AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Wed, Apr 03, 2024 at 07:11:04AM +0200, Greg KH wrote:
> > > Side note: I have no idea why the stable team backported those patches
> > > and no option on whether that was wise, just trying to help finding the best
> > > solution forward from the current state of things.
> > 
> > The Fixes: tag triggered it, that's why they were backported.
> > 
> > > > which would
> > > > be far too invasive for -stable, thus no Cc: stable.
> > > >
> > > > I didn't know a Fixes
> > > > tag automatically triggers backport to -stable. I will keep that in mind for
> > > > future.
> > > 
> > > /me fears that more and more developers due to situations like this will
> > > avoid Fixes: tags and wonders what consequences that might have for the
> > > kernel as a whole
> > 
> > The problem is that we have subsystems that only use Fixes: and not cc:
> > stable which is why we need to pick these up as well.  Fixes: is great,
> > but if everyone were to do this "properly" then we wouldn't need to pick
> > these other ones up, but instead, it's about 1/3 of our volume :(
> > 
> > I'll gladly revert the above series if they shouldn't have been
> > backported to stable, but from reading them, it seemed like they were
> > fixing an issue that was serious and should have been added to stable,
> > which is why they were.
> 
> Oh, yeah, they're fixing an issue. It's just that the issue is relatively
> confined peformance degradation and the fix is really invasive, so not a
> great -stable candidate. At the very least, they'd need a log longer cooking
> time in mainline before being considered for -stable backport.

Ok, I'll go revert them all now.  I did some test builds here with them
reverted and they seem sane.  I'll push out some -rcs with just the
reverts to at least fix the regressions found in the 6.8.y tree now.

> My intention w/ Fixes: wasn't triggering -stable backport at all, so it's a
> miscommunication. From now on, I'll keep in mind that Fixes: does trigger
> backports. I'm not too worried about not using it as the fixee commit can be
> mentioned in the commit message.

No worries, if you want, we can add any files/paths to our "ignore
Fixes: tags, only take cc: stable ones" that we have for many parts of
the kernel already, where maintainers are good and properly tag stuff.
Just let me know.

thanks,

greg k-h

  reply	other threads:[~2024-04-03 16:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02  8:08 Hibernate stuck after recent kernel/workqueue.c changes in Stable 6.6.23 Linux regression tracking (Thorsten Leemhuis)
2024-04-03  0:38 ` Tejun Heo
2024-04-03  4:26   ` Linux regression tracking (Thorsten Leemhuis)
2024-04-03  5:11     ` Greg KH
2024-04-03 15:22       ` Tejun Heo
2024-04-03 16:10         ` Greg KH [this message]
2024-04-04 15:36           ` Do we need a "DoNotBackPort" tag? (was: Re: Hibernate stuck after recent kernel/workqueue.c changes in Stable 6.6.23) Linux regression tracking (Thorsten Leemhuis)
2024-04-04 15:44             ` Greg KH
2024-04-04 15:56               ` Do we need a "DoNotBackPort" tag? Linux regression tracking (Thorsten Leemhuis)
2024-04-05  2:54                 ` Theodore Ts'o
2024-04-05  4:24                   ` Greg KH
2024-04-11  5:30                   ` Thorsten Leemhuis

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=2024040319-doorbell-ecosystem-7d31@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tj@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