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@xxxxxxxxxxxxxxxxxxx> 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? Right now we HAVE to pick up the Fixes: tagged commits in those
subsystems as you are missing lots of real fixes. I just quick looked
and noticed 8cf0a1bc1287 ("capabilities: fix potential memleak on error
path from vfs_getxattr_alloc()") which you should have tagged, right?
In fact, I've considered most of the LSM code as a "we never tag
anything for stable so we rely on the Fixes: pickup to clean up after
us" subsystem. We have many of those in the kernel, so you are in good
company :)
> I could start dropping the 'Fixes:' tag from non-stable tagged
> commits, but that's a step backwards in my opinion.
If a commit has fixes: why wouldn't it be ok for stable trees? That
feels very odd to me.
Anyway, if you really want, yes, we can add you to the "list of
subsystems we do not pick anything for except by explicit cc: stable
marking" that we have, but note, that feels wrong to me based on the
very low number of patches being tagged for these directories over time.
> I could start replying to every -stable backport email notice, but
> that seems like a lot of unnecessary work for something that was never
> marked for -stable in the first place. I'm guessing it would also add
> some additional management/testing burden to the -stable folks as
> well.
We have a list, so if you really want it, we can add you to it. But can
you point out any Fixes: commits that we backported that we shouldn't
have? If so, why was a Fixes: tag on it?
thanks,
greg k-h
