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]

Date:   Fri, 4 May 2018 10:40:55 -0700
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Theodore Y. Ts'o" <tytso@....edu>,
        Jani Nikula <jani.nikula@...el.com>,
        David Howells <dhowells@...hat.com>,
        Sasha Levin <Alexander.Levin@...rosoft.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "ksummit-discuss@...ts.linuxfoundation.org" 
        <ksummit-discuss@...ts.linuxfoundation.org>, "w@....eu" <w@....eu>
Subject: Re: [Ksummit-discuss] bug-introducing patches

On Fri, May 04, 2018 at 09:09:32AM -0400, Theodore Y. Ts'o wrote:
> On Fri, May 04, 2018 at 03:31:17PM +0300, Jani Nikula wrote:
> > On Fri, 04 May 2018, David Howells <dhowells@...hat.com> wrote:
> > > Sasha Levin via Ksummit-discuss wrote:
> > >
> > >> 	Cc: stable@...r.kernel.org # commit-id-of-(2)
> >
> > This has been documented since
> > 
> > commit 8e9b9362266dd16255473c080d846b13e27247bf
> > Author: Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
> > Date:   Sun Dec 6 12:24:31 2009 +0100
> > 
> >     Doc/stable rules: add new cherry-pick logic
> > 
> > in v2.6.33 so seems like there should have been enough time to fix the
> > tools.
> 
> The problem is that it's not being *used* that way.  In fact, that
> documentation is arguably out of date.  When it does get used, it's
> used to indicate which kernels the stable patch applies.  You have to
> go pretty far back before you find that suggested usage.  Run:
> 
> git log --grep stable@...nel.org | grep -i cc: | grep stable | grep \#
> 
> and see for yourself.  The first couple of hits:
> 
>     Cc: stable@...nel.org # 3.11
>     Cc: stable@...nel.org # 4.8+
>     Cc: stable@...nel.org # 4.8+
>     Cc: stable@...nel.org # 4.13+
>     Cc: stable@...nel.org # 4.8+
>     Cc: stable@...nel.org   # 4.13 - together with 890da9cf0983
>     Cc: stable@...nel.org # 4.13
>     Cc: stable@...nel.org # 4.13
>     Cc: stable@...nel.org   # v4.8+
>     Cc: stable@...nel.org # v4.10+
>     Cc: stable@...nel.org # v4.10+
>     Cc: stable@...nel.org # v4.10+
>     Cc: stable@...nel.org  # reverted commits were marked for stable
>     Cc: stable@...nel.org   # for the backport of the original commit
>     Cc: stable@...nel.org # v4.8+
> 
> At this point, my suggestion would be to delete the text added by the
> above-mentioned commit, and add a new syntax.  We're much more willing
> to support multiple headers, so something like this:
> 
> Stable-prereq: DEADBEEF1234: subsystem: bork bork bork....
> 
> With multiple Stable-preeq: lines allowed, where the order is
> significant, might be one way to do things.

Ugh, what?  I don't understand what you are proposing here, what we have
today is just fine, what is broken with it?

thanks,

greg k-h