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?
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?
-Doug
-Doug
-Doug