Hi,
On Thu, Apr 17, 2025 at 7:10 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Apr 14, 2025 at 08:37:36AM -0700, Doug Anderson wrote:
Hi,
On Tue, Apr 8, 2025 at 8:49 AM Doug Anderson dianders@chromium.org wrote:
Hi,
On Tue, Apr 8, 2025 at 2:17 AM gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x a5951389e58d2e816eed3dbec5877de9327fd881 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to 'stable@vger.kernel.org' --in-reply-to '2025040844-unlivable-strum-7c2f@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^..
FWIW, this patch applies cleanly for me to the top of 6.14.y if you simply apply all 5 patches in the series, all of which are CC stable. AKA these commands work
git checkout v6.14.1 # Current linux-6.14.y git cherry-pick ed1ce841245d~..a5951389e58d
Where you start getting a conflict is if you also take this patch from mainline:
e3121298c7fc arm64: Modify _midr_range() functions to read MIDR/REVIDR internally
The merge conflict between those two series was resolved upstream in:
edb0e8f6e2e1 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
I tried again as of today's linux-6.14.y (which is 6.14.2), and the patches still apply cleanly. I can send all 5 patches to the lists if it's desired, but I'm uncertain if it's required since they all apply cleanly. Just "git cherry-pick ed1ce841245d~..a5951389e58d". They all apply cleanly all the way back to 5.15 as far as I can tell. Would I need to send the same 5 clean picks in response to every stable kernel from 5.15 all the way to 6.14?
I see all but the last one in the stable queues right now, let me try the last one...
Ok, that one also applied from 5.15.y and newer.
Thanks! Yeah, I saw a bunch go through. I'll try to check back in a few days to make sure they all show up on git.
These patches don't apply cleanly to 5.4, but that's because kernel 5.4 doesn't have `proton-pack.c`, so presumably none of the Spectre mitigations were ported back that far.
Some of the spectre stuff is present in 5.10, but it looks like not all patches are being picked there. It's probably not critical to support newer ARM cores there, but changing the default to say cores are vulnerable might be worth it? What do folks think?a
That's up to you.
I ended up finding the spectre stuff even on v5.4--it was just in a different file. However, I'm not going to attempt to do any backporting to v5.4 or v5.10 myself because:
* The original incentive for me to post this series was to add QCOM_KRYO_4XX_GOLD to the k24 list. ...but there's no support for that CPU in 5.4 upstream anyway.
* The Kryo4XX patch _did_ apply to 5.10, just the further cleanups to "assume vulnerable" failed because the 5.10 tree doesn't have all the cleanups it depended upon. Backporting it would be a bigger effort and I'm not sure what the incentive would be. I'm happy to review if someone else wants to do the backport, though.
* The patch to add newer ARM cores seems even less likely to be needed on 5.4 / 5.10 kernels. Hopefully anyone developing on those newer cores is using a newer kernel.
-Doug