[PATCH 0/7] v4.19-stable randconfig fixes
Greg Kroah-Hartman
gregkh at linuxfoundation.org
Wed Dec 19 02:12:30 AEDT 2018
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...
thanks,
greg k-h
More information about the openbmc
mailing list