On Wed, Apr 15, 2020 at 04:49:19PM +0200, Greg Kroah-Hartman wrote:
> 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
>
Interesting. Both "git cherry-pick" and "git am" (I don't even need
"git am -3") on top of v4.19.115 work fine for me. But, yes, trying
to apply the patch using the patch command does indeed fail with this
error. Wonder what git does differently when running "git am".
> > 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.
>
Ok, I'll see what I can do. I'll try to get it done in time for next
week's report.
Thanks,
Guenter
