linux-kernel - Re: [Ksummit-discuss] bug-introducing patches

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: <20180503170920.GC26754@roeck-us.net>
Date:   Thu, 3 May 2018 10:09:20 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Sasha Levin <Alexander.Levin@...rosoft.com>
Cc:     "Theodore Y. Ts'o" <tytso@....edu>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "w@....eu" <w@....eu>,
        "ksummit-discuss@...ts.linuxfoundation.org" 
        <ksummit-discuss@...ts.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 03, 2018 at 04:02:12PM +0000, Sasha Levin wrote:
> >You are misquoting me. I am saying that it would be a bad idea to hold up
> >bug fixes after -rc4, which is quite different to saying that patches
> >don't make it into stable releases fast enough. I am perfectly happy to
> >wait a week or so for a patch to soak in _mainline_ before being applied
> >to stable.
> 
> Most bug fixes that go in at that point are fixes for previous released
> kernels, what's the harm in keeping them around for longer?
> 

The ones I am mostly concerned about are fixes for CVEs, crashes, file
system corruptions, and similar. Maybe the enterprise folks don't mind
keeping those around for a month or more even though a fix is available.
I do.

> For AUTOSEL, I'd be happy to learn of issues you encounter and address
> them in my process.
> 
> I've been submitting automatically selected patches for over a year now
> and the track record for regressions is on par with patches that are
> tagged for stable.

So far it hasn't been an issue. Or, rather, not much; with more patches
applied, the percentage of regressions may be the same, but the number
of regressions is higher. My "customers" care about the number, not about
the percentage.

However, the set of test results attached below (from last night)
_is_ a problem. I don't know what changed, but something clearly did,
to the point that I am _very_ concerned about the next set of stable
releases.

Guenter

---
For v4.14.39-580-gc8cd674:

Build results:
	total: 146 pass: 98 fail: 48
Qemu test results:
	total: 100 pass: 21 fail: 79

For v4.4.131-268-ga33ce4a:

Build results:
	total: 146 pass: 92 fail: 54
Qemu test results:
	total: 127 pass: 91 fail: 36