linux-kernel - Re: [PATCH 4.14 000/173] 4.14.171-stable review

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200214062106.GA3928737@kroah.com>
Date:   Thu, 13 Feb 2020 22:21:06 -0800
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        akpm@...ux-foundation.org, shuah@...nel.org, patches@...nelci.org,
        ben.hutchings@...ethink.co.uk, lkft-triage@...ts.linaro.org,
        stable@...r.kernel.org
Subject: Re: [PATCH 4.14 000/173] 4.14.171-stable review

On Thu, Feb 13, 2020 at 06:21:46PM -0800, Guenter Roeck wrote:
> On Thu, Feb 13, 2020 at 07:18:23AM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.171 release.
> > There are 173 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat, 15 Feb 2020 15:16:41 +0000.
> > Anything received after that time might be too late.
> > 
> 
> Commit 833e09807c49 ("serial: uartps: Add a timeout to the tx empty wait")
> breaks all xilinx boot tests, here and in v4.19.y. Reverting it fixes the
> problem. that is maybe not entirely surprising, given that there were
> some 40 other commits into the same file since v4.14.

Ah, I added the fixup patch (Pavel pointed it out), but didn't push out
a -rc2 with it in it.  I'll go do that now.

> FWIW, I still think that way too many patches are being backported.

All of the patches I have been added are there either because they were
asked to be there due to the cc: stable tag, or a developer asked, or
there was a "Fixes:" tag that referenced a commit in that tree.

Yes, it looks like a lot, but people are finally getting better at
tagging their stuff, which is why we are finally getting more fixes in
the tree.  We were riding for the past 15 years before now with way too
little fixes being applied.

And this is also what testing is for, be it 1 or 200 patches a release,
they should all be able to pass testing to make us feel better that they
are "safe".  The quantity does not matter for that.

thanks,

greg k-h