Hi Tim,
tharvey@gateworks.com wrote on Tue, 25 Oct 2022 15:02:27 -0700:
On Mon, Oct 24, 2022 at 1:01 AM Miquel Raynal miquel.raynal@bootlin.com wrote:
Hi Tim,
tharvey@gateworks.com wrote on Fri, 21 Oct 2022 14:55:15 -0700:
On Fri, Sep 2, 2022 at 12:03 AM Miquel Raynal miquel.raynal@bootlin.com wrote:
Hey folks,
richard@nod.at wrote on Fri, 15 Jul 2022 09:59:10 +0200 (CEST):
----- Ursprüngliche Mail -----
> My IRC history doesn't go back far enough, but if I recall correctly > Miquel is on vacation, he would have picked up this patch for linux-next > otherwise.
Exactly.
Indeed, I was off for an extended period of time, I'm (very) slowly catching up now.
Ok, let me do a round of stable releases so that people don't get hit by this now...
Thanks a lot for doing so.
Hopefully this gets fixed up by 5.19-final.
Sure, I'll pickup this patch.
Thanks Greg & Richard for the handling of this issue.
Cheers, Miquèl
Hello All,
As Tomasz stated previously 06781a5026350 was merged in v5.19-rc4 and then was picked up by several stable kernels. While this made it into the 5.15 and 5.18 stable branches it did not make it into the following which are thus the are currently broken: 5.10.y 5.17.y
How do we get this patch applied to those stable branches as well to resolve this?
It is likely that the original patch (targeting a mainline kernel) did not apply to those branches. In this case you can adapt the fix to the concerned kernels and send it to stable@ (following the Documentation guidelines for backports).
Thanks, Miquèl
Miquèl,
Thanks for the pointer. You are correct that this patch which resolves the regression does not apply directly to 5.4/5.10/5.17 stable trees. I'm looking over https://www.kernel.org/doc/html/v4.10/process/stable-kernel-rules.html
Option 3 fits, right?
and I'm not clear what I need to put in the commit to make it clear that it only applies to those specific trees. Do I simply adjust the 'Fixes' tag to address the commit from that specific stable branch and send one for each stable branch (thus each would have a different sha in the Fixes tag) while also adding the 'commit <sha> upstream' to the top?
Here are the failures: https://lore.kernel.org/stable/165858381623360@kroah.com/ https://lore.kernel.org/stable/165858381472139@kroah.com/ https://lore.kernel.org/stable/165858381313218@kroah.com/
You should not adjust the Fixes tag, this tag should really reflect what you are trying to fix, and not some kind of target for the backport. However you're changing the commit content so you can also change the commit log, with eg. the upstream original commit somewhere there in plain text. You can target a kernel version on the Cc: stable line (see the doc) and you can also use
--subject-prefix="PATCH stable <version>"
during git-format-patch, even though I'm not sure this is actually needed, it's more like courtesy to let reviewers know what you are doing.
Here is an example, maybe not the best one (forget about the RESEND) but a typical case: https://lore.kernel.org/linux-mtd/20220223174431.1083-1-f.fainelli@gmail.com...
Thanks, Miquèl