Re: Patches to apply to stable releases

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Apr 15, 2020 at 07:21:44AM -0700, Guenter Roeck wrote:
> >> Upstream commit cc41f11a21a5 ("scsi: mpt3sas: Fix kernel panic observed on soft HBA unplug")
> >>     Fixes: c666d3be99c0 ("scsi: mpt3sas: wait for and flush running commands on shutdown/unload")
> >>     in linux-4.14.y: 3748694f1b91
> >>     Applies to:
> >>         v4.14.y
> > 
> > This also belongs to 4.19.y, 5.4.y, 5.5.y, and 5.6.y as it is cc:
> > stable.  But it doesn't backport cleanly to all, so I need a working
> > backport in order to be able to take it...
> > 
> I tracked this one down. The offending patch (c666d3be99c0) was applied
> to v4.16 and to v4.14.y. The script takes that as clue to request a backport;
> it assumes that the normal stable processs (whatever you and Sasha run to
> identify patches to apply) takes care of more recent releases, and doesn't
> look into those. This is intentional. We can change it, but I don't really
> want to duplicate your and Sasha's work.
> 
> Oops, and I completely forgot about 5.5 and 5.6. The script doesn't tell
> me (and neither about 4.9) because there is no such Chrome OS release,
> so I have to check those manually.
> 
> Either case, the patch applies cleanly to 4.19.y and later for me.
> Did you see conflicts, or build problems, when trying to apply it ?

When trying to patch 4.19.y:
	checking file drivers/scsi/mpt3sas/mpt3sas_scsih.c
	Hunk #1 succeeded at 9919 (offset 11 lines).
	Hunk #2 FAILED at 9992.
	1 out of 2 hunks FAILED

> Note that we don't really care about mpt3sas; missing that patch
> is not a problem for us. My qemu emulations test basic mpt3sas
> operation, but not unplug situations, so I would not miss the patch
> there either. So feel free to ignore/drop if it causes issues.

I've asked the developers for a backport, if they think it is needed.

> >> Upstream commit 82f04bfe2aff ("tools: gpio: Fix out-of-tree build regression")
> >>     Fixes: 0161a94e2d1c ("tools: gpio: Correctly add make dependencies for gpio_utils")
> >>     in linux-4.14.y: f71e52cb3270
> >>     in linux-4.19.y: 036588ec6888
> >>     Applies to:
> >>         v4.14.y, v4.19.y
> > 
> > Also belongs to 4.9.y, 5.6.y, 5.5.y, and 5.4.y.  Also has a cc: stable
> > that I hadn't gotten to yet, now applied.
> > 
> The offending patch (0161a94e2d1c) is in 5.4, and thus the script assumes
> that the normal stable process would take care of it. Same situation as
> above. And I forgot to check 4.9, sorry.
> 
> >> Upstream commit 3e487d2e4aa4 ("PCI: pciehp: Fix indefinite wait on sysfs requests")
> >>     Fixes: 157c1062fcd8 ("PCI: pciehp: Avoid returning prematurely from sysfs requests")
> >>     in linux-4.19.y: 248e65f3220e
> >>     in linux-5.4.y: 9bd9d123399b
> >>     Applies to:
> >>         v4.19.y, v5.4.y
> > 
> > Already queued up yesterday, and to 5.5.y and 5.6.y.
> > 
> >> Upstream commit 8644772637de ("mm: Use fixed constant in page_frag_alloc instead of size + 1")
> >>     Fixes: 2c2ade81741c ("mm: page_alloc: fix ref bias in page_frag_alloc() for 1-byte allocs")
> >>     in linux-4.14.y: a977209627ca
> >>     in linux-4.19.y: 33e83ea302c0
> >>     Applies to:
> >>         v4.14.y, v4.19.y
> > 
> > Also needed in 4.9.y, now queued up.
> > 
> >> Upstream commit 2abb5792387e ("net: qualcomm: rmnet: Allow configuration updates to existing devices")
> >>     Fixes: 1dc49e9d164c ("net: rmnet: do not allow to change mux id if mux id is duplicated")
> >>     in linux-4.19.y: 48c5bfbbcec1
> >>     in linux-5.4.y: 835bbd892683
> >>     Applies to:
> >>         v4.19.y, v5.4.y
> > 
> > Normally I wait for DavidM to send me these as they are also applicable
> > to 5.6.y and 5.5.y.  Now queued up.
> > 
> >> Upstream commit 36eb7dc1bd42 ("cpufreq: imx6q: Fixes unwanted cpu overclocking on i.MX6ULL")
> >>     Fixes: 2733fb0d0699 ("cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull")
> >>     in linux-4.19.y: 4ef576e99d29
> >>     Applies to:
> >>         v4.19.y
> > 
> > Queued up yesterday.
> > 
> >> Upstream commit 4c7eeb9af3e4 ("arm64: dts: allwinner: h6: Fix PMU compatible")
> >>     Fixes: 7aa9b9eb7d6a ("arm64: dts: allwinner: H6: Add PMU mode")
> >>     in linux-4.19.y: 8f1046b33f1b
> >>     in linux-5.4.y: 02dfae36b03f
> >>     Applies to:
> >>         v4.19.y, v5.4.y
> > 
> > Also needed in 5.5.y and 5.6.y.
> > 
> >> Upstream commit ae769d355664 ("ALSA: pcm: oss: Fix regression by buffer overflow fix")
> >>     Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
> >>     in linux-4.14.y: 5ac3462e1921
> >>     in linux-4.19.y: 8c5bd5520334
> >>     in linux-5.4.y: 07ec940ceda5
> >>     Applies to:
> >>         v4.14.y, v4.19.y, v5.4.y
> > 
> > Already queued up yesterday all the way back to 4.4.y and 4.9.y as well
> > because f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
> > went that far back.  Did your scripts miss that?
> > 
> It was dropped from 4.4 because it causes a conflict when trying to apply
> it to chromeos-4.4. I'll see what I can do about that.
> 
> >> Upstream commit 82e0516ce3a1 ("sched/core: Remove duplicate assignment in sched_tick_remote()")
> >>     Fixes: ebc0f83c78a2 ("timers/nohz: Update NOHZ load in remote tick")
> >>     in linux-5.4.y: 166d6008fa2a
> >>     Applies to:
> >>         v5.4.y
> > 
> > Also applied to 5.5.y and 5.6.y
> > 
> >> Upstream commit 4ae7a3c3d7d3 ("arm64: dts: allwinner: h5: Fix PMU compatible")
> >>     Fixes: c35a516a4618 ("arm64: dts: allwinner: H5: Add PMU node")
> >>     in linux-5.4.y: 5a241d7bf1e6
> >>     Applies to:
> >>         v5.4.y
> > 
> > Also applied to 5.5.y and 5.6.y
> > 
> >> Upstream commit 9b8b17541f13 ("mm, memcg: do not high throttle allocators based on wraparound")
> >>     Fixes: e26733e0d0ec ("mm, memcg: throttle allocators based on ancestral memory.high")
> >>     in linux-5.4.y: 61cfbcce9e09
> >>     Applies to:
> >>         v5.4.y
> > 
> > Hadn't gotten to it yet, also queued up for 5.5.y and 5.6.y
> > 
> >> Upstream commit 8c5c66052920 ("nvme-fc: Revert "add module to ops template to allow module references"")
> >>     Fixes: 863fbae929c7 ("nvme_fc: add module to ops template to allow module references")
> >>     in linux-4.14.y: a123233fc320
> >>     in linux-4.19.y: 6c786e656cd9
> >>     in linux-5.4.y: 6b49a5a9eb46
> >>     Applies to:
> >>         v4.14.y, v4.19.y, v5.4.y
> > 
> > Queued up yesterday, also for 5.5.y and 5.6.y.
> > 
> > Many thanks for these, I think they should now all be handled.
> > 
> 
> Thanks a lot, and sorry for missing 5.5/5.6. Those really completely
> slipped my mind.
> 
> So the big question is if we should report patches such as 82f04bfe2aff,
> ie patches missing from stable releases where the offending patch was
> not applied to a stable release but to mainline. This would overlap
> with Sasha's script, though, so I am not sure if it would be a good
> idea. What is your take ?

The "offending" patch in that case was applied to mainline and all the
way back to 4.9.y (was in 4.9.204) , so yes, it is good to be notified
of this.

thanks,

greg k-h