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 17:13:17 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     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 10:40:55AM -0700, Greg KH wrote:
> Ugh, what?  I don't understand what you are proposing here, what we have
> today is just fine, what is broken with it?

What we have today is this:

     Cc: stable@...nel.org # 3.11
     Cc: stable@...nel.org # 4.8+
     Cc: stable@...nel.org # 4.8+

Jani was suggesting something documented which doesn't match current
practice.  See commit 8e9b9362266d, which describes something like this:

     Cc: <stable@...nel.org> # .32.x: a1f84a3: sched: Check for idle
     Cc: <stable@...nel.org> # .32.x: 1b9508f: sched: Rate-limit newidle
     Cc: <stable@...nel.org> # .32.x: fd21073: sched: Fix affinity logic

... to specify prereqisite commits needed to backport the commit in
question.  I am proposing that we delete what is in
stable_kernel_rules.rst, because it doesn't match with current
practice.

If it is necessary to explicitly specify prerequisites (as opposed to
having scripts or stable maintainers guess or figure things out
manually), then something like this might be better:

Stable-prereq: DEADBEEF1234: subsystem: bork bork bork....

If it's not necessary, fine.  But we should still delete what is
currently documented in stable_kernel_rules and was introduced in
8e9b9362266d, because it doesn't describe current practice.

						- Ted