All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Paul Moore <paul@paul-moore.com>
Cc: Luiz Capitulino <luizcap@amazon.com>,
	sashal@kernel.org, stable@vger.kernel.org
Subject: Re: Possible build time regression affecting stable kernels
Date: Wed, 28 Jun 2023 20:33:08 +0200	[thread overview]
Message-ID: <2023062846-outback-posting-dfbd@gregkh> (raw)
In-Reply-To: <CAHC9VhRuc5jSK7xODqtBvhUmunov+PVVQyLb8oDP8k0pLq_P-g@mail.gmail.com>

On Thu, Jun 01, 2023 at 02:39:00PM -0400, Paul Moore wrote:
> On Thu, Jun 1, 2023 at 11:51 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Jun 01, 2023 at 10:56:24AM -0400, Paul Moore wrote:
> > > On Thu, Jun 1, 2023 at 9:20 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > On Thu, Jun 01, 2023 at 09:13:21AM -0400, Luiz Capitulino wrote:
> > >
> > > ...
> > >
> > > > > Yes. I'm reporting this here because I'm more concerned with -stable kernels since
> > > > > they're more likely to be running on older user-space.
> > > >
> > > > Yeah, we are bug-compatible!  :)
> > >
> > > While I really don't want to go back into the old arguments about what
> > > does, and does not, get backported to -stable, I do want to ask if
> > > there is some way to signal to the -stable maintainers that a patch
> > > should not be backported?  Anything coming from the LSM, SELinux, or
> > > audit trees that I believe should be backported is explicitly marked
> > > with a stable@vger CC, as documented in stable-kernel-rules.rst,
> > > however it is generally my experience that patches with a 'Fixes:' tag
> > > are generally pulled into the -stable releases as well.
> >
> > Really?
> 
> Yes, really.
> 
> > Right now we HAVE to pick up the Fixes: tagged commits in those
> > subsystems as you are missing lots of real fixes.
> 
> This starts to bring us back to the old argument about what is
> appropriate for -stable, but I've been sticking as close as possible
> to what is documented in stable-kernel-rules.rst which (ignoring
> things like HW enablement) advises that only patches which fix build
> issues or "serious issues" should be considered for -stable.  I
> consider every bug fix that goes into the LSM, SELinux, and audit
> trees to see if it meets those criteria, if it does I mark it with a
> -stable tag, if not I leave the -stable tag and ensure it carries a
> 'Fixes:' tag if it makes sense and an appropriate root-cause commit is
> identified.
> 
> We definitely have different opinions on where the -stable bug fix
> threshold lies.  I am of the opinion that every -stable backport
> carries risk, and I consider that when deciding if a commit should be
> marked for -stable.  I do not believe that every bug fix, or every
> commit with a 'Fixes:' tag, should be backported to -stable.

Ok, I'll not argue here, but it feels like there is a lack of changes
for some of these portions of the kernel that end up in stable kernels.
I'll trust you on this.

So, can I get a directory list or file list of what we should be
ignoring for the AUTOSEL and "Fixes: only" tools to be ignoring?

thanks,

greg k-h

  reply	other threads:[~2023-06-28 18:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01  2:12 Possible build time regression affecting stable kernels Luiz Capitulino
2023-06-01  6:06 ` Greg KH
2023-06-01 13:13   ` Luiz Capitulino
2023-06-01 13:20     ` Greg KH
2023-06-01 13:26       ` Luiz Capitulino
2023-06-01 14:13         ` Greg KH
2023-06-01 14:22           ` Luiz Capitulino
2023-06-01 14:56       ` Paul Moore
2023-06-01 15:51         ` Greg KH
2023-06-01 18:39           ` Paul Moore
2023-06-28 18:33             ` Greg KH [this message]
2023-06-28 23:33               ` Paul Moore
2023-06-29  8:43                 ` Greg KH
2023-06-29 15:55                   ` Paul Moore
2023-06-29 16:07                     ` Greg KH
2023-06-29 16:20                       ` Paul Moore
2023-06-01 14:27 ` Paul Moore
2023-06-01 15:02   ` Luiz Capitulino
2023-06-01 15:45     ` Paul Moore
2023-06-01 15:50       ` Luiz Capitulino
2023-06-01 17:05         ` Greg KH
2023-06-01 18:10           ` Paul Moore
2023-06-01 18:15             ` Luiz Capitulino
2023-06-01 18:41               ` Paul Moore

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=2023062846-outback-posting-dfbd@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=luizcap@amazon.com \
    --cc=paul@paul-moore.com \
    --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 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.