linux-kernel - Re: [PATCH 0/7] v4.19-stable randconfig fixes

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: <20181218162021.GZ2746@sasha-vm>
Date:   Tue, 18 Dec 2018 11:20:21 -0500
From:   Sasha Levin <sashal@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Arnd Bergmann <arnd@...db.de>, stable@...r.kernel.org,
        Andrew Jeffery <andrew@...id.au>,
        Andy Gross <andy.gross@...aro.org>, bp@...en8.de,
        Daniel Drake <dsd@...top.org>,
        David Brown <david.brown@...aro.org>, dou_liyang@....com,
        Ingo Molnar <mingo@...hat.com>,
        "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
        Jens Frederich <jfrederich@...il.com>,
        Lubomir Rintel <lkundrak@...sk>,
        Mark Rutland <mark.rutland@....com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Rob Clark <robdclark@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, freedreno@...ts.freedesktop.org,
        linux-i2c@...r.kernel.org, openbmc@...ts.ozlabs.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-aspeed@...ts.ozlabs.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH 0/7] v4.19-stable randconfig fixes

On Tue, Dec 18, 2018 at 04:12:30PM +0100, Greg Kroah-Hartman wrote:
>On Mon, Dec 17, 2018 at 07:20:28PM -0500, Sasha Levin wrote:
>> On Fri, Dec 14, 2018 at 11:10:05PM +0100, Arnd Bergmann wrote:
>> > Hi Greg,
>> >
>> > I did some randconfig testing on linux-4.19 arm/arm64/x86. So far I needed
>> > 27 patches, most of which are also still needed in mainline Linux. I
>> > had submitted some before, and others were not submitted previously
>> > for some reason. I'll try to get those fixed in mainline and then
>> > make sure we get them into 4.19 as well.
>> >
>> > This series for now contains four patches that did make it into mainline:
>> >
>> > 2e6ae11dd0d1 ("slimbus: ngd: mark PM functions as __maybe_unused")
>> > 33f49571d750 ("staging: olpc_dcon: add a missing dependency")
>> > 0eeec01488da ("scsi: raid_attrs: fix unused variable warning")
>> > 11d4afd4ff66 ("sched/pelt: Fix warning and clean up IRQ PELT config")
>> >
>> > Feel free to either cherry-pick those from mainline or apply the
>> > patch from this series, whichever works best for you.
>> >
>> > The other three patches are for warnings in code that got removed in
>> > mainline kernels:
>> >
>> > 3e9efc3299dd ("i2c: aspeed: Handle master/slave combined irq events properly")
>> > 972910948fb6 ("ARM: dts: qcom: Remove Arrow SD600 eval board")
>> > effec874792f ("drm/msm/dpu: Remove dpu_dbg")
>> >
>> > My feeling was that it's safer to just address the warning by fixing
>> > the code correctly in each of these cases, but if you disagree,
>> > applying the mainline change should work equally well, so decide
>> > for yourself.
>>
>> Thanks Arnd, I took the series as is.
>>
>> We really need to discuss how -stable deals with removed code upstream.
>> For some cases, we should probably follow suit and remove it from
>> -stable as well (I'm mostly thinking dodgy code with potential security
>> issues).
>
>It would be nice to do that at times (like lustre and ipx), but it's
>good to keep that code around as maybe someone is using it?  I don't
>know, it's a tough call...

Yeah, it's really a case-by-case basis. I'm really concerned about an
unmaintained piece of code in stable kernels, no one actually fixes bug
in it.

With the example here where that eval board was removed because no one
was using it is a great example of code we should be removing from
stable trees as well. If no one is using it - great! but if someone
does, then the removal should be reverted upstream as well.

--
Thanks,
Sasha