Re: [PATCH 4.19 0/3] Backport handling -ESTALE policy update failure to 4.19

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Feb 03, 2023 at 08:49:05AM +0100, Greg KH wrote:
> On Fri, Feb 03, 2023 at 08:44:51AM +0100, Greg KH wrote:
> > On Fri, Feb 03, 2023 at 09:10:13AM +0800, Guozihua (Scott) wrote:
> > > On 2023/2/3 1:20, Sasha Levin wrote:
> > > > On Wed, Feb 01, 2023 at 10:39:49AM +0800, GUO Zihua wrote:
> > > >> This series backports patches in order to resolve the issue discussed
> > > >> here:
> > > >> https://lore.kernel.org/selinux/389334fe-6e12-96b2-6ce9-9f0e8fcb85bf@huawei.com/
> > > >>
> > > >> This required backporting the non-blocking LSM policy update mechanism
> > > >> prerequisite patches.
> > > > 
> > > > Do we not need this on newer kernels? Why only 4.19?
> > > > 
> > > Hi Sasha.
> > > 
> > > The issue mentioned in this patch was fixed already in the newer kernel.
> > > All three patches here are backports from mainline.
> > 
> > Ok, now queued up, thanks.
> 
> Nope, I've now dropped them all as you did not include the needed fix up
> commits as well.  We can not add patches to the stable tree that are
> known broken, right?
> 
> How well did you test this?  I see at least 3 missing patches that you
> should have had in this patch series for it to work properly.

Ah, you didn't even test this series, as it breaks the build
as-submitted.

{sigh}

In order for us to take this, I think you need to find someone else who
will validate your patch series _FIRST_ before submitting it to us.  And
I want their tested-by on them validating that it did actually work (if
for no other reason than to have someone else be willing to be
responsible if things go bad.)

Breaking our builds and forcing me to point out missing patches is not
how the stable kernel process works in any sane manner.

greg k-h