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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6cb72764-29a3-73f1-cfe3-9e972d975333@huawei.com>
Date:   Mon, 6 Feb 2023 10:55:26 +0800
From:   "Guozihua (Scott)" <guozihua@...wei.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     Sasha Levin <sashal@...nel.org>, <stable@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <zohar@...ux.ibm.com>,
        <paul@...l-moore.com>, <luhuaxin1@...wei.com>
Subject: Re: [PATCH 4.19 0/3] Backport handling -ESTALE policy update failure
 to 4.19

On 2023/2/3 15:54, Greg KH wrote:
> 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
Sorry for the burden. Still trying to work out how things are done here.

It seems that when I test it out, it did not build with the allmodconfig
which would report an error. And by the "fixes up commit" I supposed it
mean the commits with the "Fixes" tag points to the three commits I
submitted.

I'll submit a new patch set soon, which would include the following
fixes commits.

Again, sorry for the burden.

-- 
Best
GUO Zihua