mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2025-01-16 02:14:58 +00:00
33024 Commits
Author | SHA1 | Message | Date | |
---|---|---|---|---|
Linus Torvalds
|
be54864552 |
s390:
* fix a latent bug when the kernel is compiled in debug mode * two small UCONTROL fixes and their selftests arm64: * always check page state in hyp_ack_unshare() * align set_id_regs selftest with the fact that ASIDBITS field is RO * various vPMU fixes for bugs that only affect nested virt PPC e500: * Fix a mostly impossible (but just wrong) case where IRQs were never re-enabled * Observe host permissions instead of mapping readonly host pages as guest-writable. This fixes a NULL-pointer dereference in 6.13 * Replace brittle VMA-based attempts at building huge shadow TLB entries with PTE lookups. -----BEGIN PGP SIGNATURE----- iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmeDrZkUHHBib256aW5p QHJlZGhhdC5jb20ACgkQv/vSX3jHroMX/wf/VPTDn+T0EcWBduH+hJ/g0uxM0TqM vHmoL8sXrH9yVrqcdlOVXDc9R6h7q44cuOM/ZPBZuR4QAJqcL7b9KDDQWyOphzQt U6rKDbnDZyEAC5Ti586qncKGoEv7vgL2LOVW5MUyyYzyWAKmNs2HNSIQkKmDEPiQ KXWMhtncC3x+TbesbwMxwE/F94M7PFVynaoODH/dY8C7ZsPykIBRuUz4WSE/411b Dy8TOYyesPg4pCT8YASHCt8PIwwBUXpEUfhEqElOGM4I3rOfWXFe1w1VyizXLyO5 lULZ3zfP6+jlWxbz9Nyvb5rSRJO8a6PfmqhsbFavGQau0u/3AR2cLTA92w== =UpHe -----END PGP SIGNATURE----- Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull kvm fixes from Paolo Bonzini: "The largest part here is for KVM/PPC, where a NULL pointer dereference was introduced in the 6.13 merge window and is now fixed. There's some "holiday-induced lateness", as the s390 submaintainer put it, but otherwise things looks fine. s390: - fix a latent bug when the kernel is compiled in debug mode - two small UCONTROL fixes and their selftests arm64: - always check page state in hyp_ack_unshare() - align set_id_regs selftest with the fact that ASIDBITS field is RO - various vPMU fixes for bugs that only affect nested virt PPC e500: - Fix a mostly impossible (but just wrong) case where IRQs were never re-enabled - Observe host permissions instead of mapping readonly host pages as guest-writable. This fixes a NULL-pointer dereference in 6.13 - Replace brittle VMA-based attempts at building huge shadow TLB entries with PTE lookups" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: e500: perform hugepage check after looking up the PFN KVM: e500: map readonly host pages for read KVM: e500: track host-writability of pages KVM: e500: use shadow TLB entry as witness for writability KVM: e500: always restore irqs KVM: s390: selftests: Add has device attr check to uc_attr_mem_limit selftest KVM: s390: selftests: Add ucontrol gis routing test KVM: s390: Reject KVM_SET_GSI_ROUTING on ucontrol VMs KVM: s390: selftests: Add ucontrol flic attr selftests KVM: s390: Reject setting flic pfault attributes on ucontrol VMs KVM: s390: vsie: fix virtual/physical address in unpin_scb() KVM: arm64: Only apply PMCR_EL0.P to the guest range of counters KVM: arm64: nv: Reload PMU events upon MDCR_EL2.HPME change KVM: arm64: Use KVM_REQ_RELOAD_PMU to handle PMCR_EL0.E change KVM: arm64: Add unified helper for reprogramming counters by mask KVM: arm64: Always check the state from hyp_ack_unshare() KVM: arm64: Fix set_id_regs selftest for ASIDBITS becoming unwritable |
||
Paolo Bonzini
|
5c99a684c9 |
KVM/arm64 changes for 6.13, part #3
- Always check page state in hyp_ack_unshare() - Align set_id_regs selftest with the fact that ASIDBITS field is RO - Various vPMU fixes for bugs that only affect nested virt -----BEGIN PGP SIGNATURE----- iI0EABYIADUWIQSNXHjWXuzMZutrKNKivnWIJHzdFgUCZ3Cfbxccb2xpdmVyLnVw dG9uQGxpbnV4LmRldgAKCRCivnWIJHzdFuc4AQDcDPzJAmtA2xem+JOTPwTOl4Fk TKDfwes3zZ/42/BA8wEA2X4vKcSwQTujdCpRrRiQvegn3pcT4V9oo9TB0kzjoQU= =KEa8 -----END PGP SIGNATURE----- Merge tag 'kvmarm-fixes-6.13-3' of https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 changes for 6.13, part #3 - Always check page state in hyp_ack_unshare() - Align set_id_regs selftest with the fact that ASIDBITS field is RO - Various vPMU fixes for bugs that only affect nested virt |
||
Arnd Bergmann
|
5391c5d8e6 |
Fixed card-detect on one board and some missing properties added.
-----BEGIN PGP SIGNATURE----- iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmeAXgAQHGhlaWtvQHNu dGVjaC5kZQAKCRDzpnnJnNEdgfi3CACZduWgY5wxOLWeXBFhGRjeVpld0fM7EYdO VTuMgIjQTDo8pi+uGmP49HP/Uz9w4YxTbhAT5lBwdBnHs0SrTMWUZcp6R146ihbc IQ5SogUdK0WpvaRk0hnntZ1kzbje8xP2O0wwPLi7pf+gDgNvzbnMQzba4n010KII eM2yzQJ78szoNa4WfO8q8U4J2mNEjzdNX0bNw9CqUIvQxB7ndhnAlkIlZghisAXq WSd4w/EG0hXbd17KNR1/ZnyPzxyu1z2/2RS71Up4c35fYn0a57x6kqdzSyuNMbuF jwlR7wBW9FTWb/iMRhYo4ACx5DAutZytpr5RjmLVtSzEbZqdE1MP =8yDt -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmeBVvsACgkQYKtH/8kJ Uic6UQ/+KqYxW6yca/l3NfRz8v+LzCAQyUFTM7VJnfsVmkg4A2SimrKbt93OWJXU MFoPDI9SwNrrq7yFSSxuzEfdoROIfxEK1JBUXSFDTdWU1uqGJfsTAMEINoR0uCC1 A21qNz4Tr8S9nYpgvaQCssH88HM736QkPiwhS1cTZHHaduU585a4ycDqCZSXYdj7 nUM0SD6sJ6K8UN32hj7eD+sYIV/plSHIdybAlcpUNRR/GLLTxoReb7fkDeXVBHkE NhS1L1T3XWXfHJJZLZhVA1gJmpicUBJeX4UgbVeNV97F4UxJL4JcU7B2kdJppl/9 W5awxVA3ANC7jB94N+hY58MOA+qfcCwLIL3NsyPjghS61XGMRGRw02EI0WymO9Zg puD0NVvH8SMQ1n/5ryrlCoEdDbjc2H/P+v2VmohY+oPzThsjrcy4CpQVGS2nOAAx 3SlUqUxYz97YeewR9D3wunpFtfm5grlBG17Xfzf8SK5J5MoDbl3QGSvxojlsz7+p piQjyntdzPUbsIQGMUpn0FVHDRjPhE2AotacHTmgJXEcFf1C6d1f9VrR8WTEXmhQ uFrsk3bslVXV4mlHMAhA+z2OvwPRaeOziFk2r9k/XE+hdbut29CQpUZbTwO/Rqn8 bgj80v5dZMac+u1FcA1lcs7FUTDCiLvFPbNor31FMmsd3KmxgDU= =aKk7 -----END PGP SIGNATURE----- Merge tag 'v6.13-rockchip-dtsfixes1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes Fixed card-detect on one board and some missing properties added. * tag 'v6.13-rockchip-dtsfixes1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: arm64: dts: rockchip: add hevc power domain clock to rk3328 arm64: dts: rockchip: Fix the SD card detection on NanoPi R6C/R6S arm64: dts: rockchip: rename rfkill label for Radxa ROCK 5B arm64: dts: rockchip: add reset-names for combphy on rk3568 Link: https://lore.kernel.org/r/2914560.yaVYbkx8dN@diego Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
Arnd Bergmann
|
00f63a0f5f |
i.MX fixes for 6.13:
- Add fallback for i.MX8QM ESAI compatible to fix a dt-schema warning caused by bindings update - Fix uSDHC1 clock for i.MX RT1050 - Enable SND_SOC_SPDIF in imx_v6_v7_defconfig to fix a regression caused by an i.MX6 SPDIF sound card change in DT - Fix address length of i.MX95 netcmix_blk_ctrl -----BEGIN PGP SIGNATURE----- iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmdyX50UHHNoYXduZ3Vv QGtlcm5lbC5vcmcACgkQUFdYWoewfM7Yhgf/YFbJU/RQ/FW3Bp/ZGu8HA/gfW0gM s1Zv/vfydHXXiecPLWx9+TUuk0JtVPjgijzmCTbBhM1he+HcCQy72aoFY+ttDhKj MOSOnHdFYroB/ydsPQ+RlqPkPj36zysH7iWR/sZ5d3/Vfo/3q6dxvkG5SfdilO/i cGwXvQRuovRea70zdT7VOww8vdaagvaik+wrLYTGyh94pth7SDP/Z09prvzYApO5 EigO39meVA+r65vYRYYtgPRkcsE+ZpGM5E4sTEy7xWmvTxz5VC9NhnoWy7XeNSVh ku9wXAxE2O5HQp5dxx+rMZUDetZ0VM7BJXHNBCHSqNJzdHY28/NymVtT7w== =lwDB -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmeARf8ACgkQYKtH/8kJ UidqKg//f0y3prnNbWF6KTZ7Rk8vVEoVgXDKO2cBMTxI8ofRwxQD0TCQ8hr19fOW Wa+KKUC4LMDzSYvreQMZP/y8anuetjVj+0UQ+GkpGUiBcSwq4EWoomDwFMHT1lRR 82FcBpWJ6zfRrf0l0kcsHu+2+T3Z/Oxt4YHiXC2WK4gMZHeTcmGEG2gweLjqxlvm KwLgD9RAGh11ab3LfMHriZLUZX9P4/MNAZ+QRmyBXHizgEaSdIhLCYAyYfDoX5Oy kqHIz9U8YtfyVLqS7PMlFidQW6DPmP7abwmnEqZZughmDDmv+p7FBZs3qHhm7zVa 94/YNpS7BT7Ucvib9oM8cpR/yrVLL39TbV3ycKvfo8q1Rm2ooouaVD3+8nbk6f9M qCi1qkEyjeB3a/7+IbyhQkSyqaEeQLF6n4PwzBenF50VzSQA2I7WJg1Mp437GHgh wLU8XAFMCDLzvkqSTJTObtYY61S+n1pnWgKHQm67NatDeMhC+nx9eyRxHI7zsek2 IvQBTBxErXfTf7MIBM2WNDbwqqUPpmwn5LWmnSj7kYHuRXHOvc4+41UXOfUCNQG3 MqzKXq0SbuoMkG6rh27YDjfE6WjXeuwkXOUbULvNc2Nd8q5ppx07kOEcrHUPlY0b 6mhDb2oIo9f8Ps6Ujx6KWpz/S3cuUo+ANku4b56JAR0UobeoA3w= =gT/D -----END PGP SIGNATURE----- Merge tag 'imx-fixes-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 6.13: - Add fallback for i.MX8QM ESAI compatible to fix a dt-schema warning caused by bindings update - Fix uSDHC1 clock for i.MX RT1050 - Enable SND_SOC_SPDIF in imx_v6_v7_defconfig to fix a regression caused by an i.MX6 SPDIF sound card change in DT - Fix address length of i.MX95 netcmix_blk_ctrl * tag 'imx-fixes-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: imxrt1050: Fix clocks for mmc ARM: imx_v6_v7_defconfig: enable SND_SOC_SPDIF arm64: dts: imx95: correct the address length of netcmix_blk_ctrl arm64: dts: imx8-ss-audio: add fallback compatible string fsl,imx6ull-esai for esai Link: https://lore.kernel.org/r/Z3Jf9zbv/xH3YzuB@dragon Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
Arnd Bergmann
|
627522c8bf |
Qualcomm Arm64 DeviceTree fixes for v6.13
Revert the enablement of OTG support on primary and secondary USB Type-C controllers of X1 Elite, for now, as this broke support for USB hotplug. Disable the TPDM DCC device on SA8775P, as this is inaccessible per current firmware configuration. Also correct the PCIe "addr_space" region to enable larger BAR sizes. Also fix the address space of PCIe6a found in X1 Elite. -----BEGIN PGP SIGNATURE----- iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmd3UBEVHGFuZGVyc3Nv bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FYPMP/RAdO4vAnJ034xLLOp0R/hpAFVew /WOZf4WgHwjmC89VEp95zabxMB3oWn6Wdk7mKN/+NTcKHs7cMLQ/d8aVX67mlomG i0q757Wzgm2GSioHbeKQ9me/rNOCRgpx8ZUZEjC64FraE/1s8Be2zTLqyX2xfUoz PMpPEUlI51IPk6vUv/aU4U1uqqTZBQINIZ7hmMei8B0FwVs9cDx/uUsGccz2AgWA i776PHKmBg8EhaJJxaXKuXl84qH7B3XrlzOTWmx2eLIUVAiId3kscsCxkJLxHlPp jWiN0TBB8sRa7q8wDVfjKOg0rBjtpTFVrdcVGTU7/Ub8aHI3YGpD4LnqBx91YqXF wa7ZhdTVdsroCSJvLG0c2cgmRm6ZfaPpOtw4x2KgrZkhPGpVInftEmHVm5uSSwhx M+D2RoGESj1mQhcJ72Kuqmrd1C8UQtF4JkDAY+5vOHf+ixt0QjAtd6URh0n9WlEl GYZvVSzHqv+fwpzkRJljiNrVK3c6/1TtEWIdm+c/jeSo02D2m/AAHJwb/nSlI875 6aOKFeVGf1IT2k5cu4cMhtpJpnkwNKz1uJfc8O5gOjYTGvLzFKFYv0nekfvCMbOS fPheUn4RAtCohSkAUB8OVFkF04iH2J/o6npiM1GPbaC61rrL/3ylhVRqzIw5Hmkz G8XTFXyiABPXFls2 =MuLc -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmeARa0ACgkQYKtH/8kJ UieF2g//WDchFn0Wk4WjeQh93kDP7JIlkmEXmCq+hfVF6fX+4ONRRhJTtH2Eacrf mhmf+tkbc9Yy3xLuvcoZafhhq2pXvtUYa/iR86XB0oYXhYuvbcE0cICNGod8V92G ZHEj5KBnU/U3vyD8d3iy5aliy44bqH9Powl63YfD8XdAbLXh8CrXeILsIZsV04WU 8fWz0/NYyst3Jtjc/HEK7CrZi4jO4mU4AncnSZn6qh7R9FPK8i5NyEpak0+ZnOcl FIJM0EfGJbESLxCOHUkkrcBiKTzBAKh8ej1xiYpfBoNOF7DtS7XlF0pXPFuyrguW MjKJl5JXppLRSEurv76iHFwUAVgtwVJ3o0dcaPCfiErcO+68JWm0+J4v5irAzBG/ s6FSePdZZI/p1ghQPs8ZAe1H9BB5jK5KNfrsE3vgKhwFf7in5/afgdestg+YYnJc fRSwU8FkrZ7pQ0QXPyjr4CRjCugnuBnIU+v5Ad9BRY26BGSnyQwVbO6K/4b6MH/p n1dSyl+2DvpAFBA+/9ZkRbfF/xBN97TvF0RN+mPwNB5v1OhNhi83lnk96EQ+WSJp QuSN0GmTQuzxg4yiA+VZDrUncJaGVdwBAuO2tQgpc+LXXon2n/dMiDDirhEgj8e3 /oQSPyg63CB+nfgWuvu/Kc4mJTbXuhsTBQ/2dP2RTyiQ09TbZQY= =rNWN -----END PGP SIGNATURE----- Merge tag 'qcom-arm64-fixes-for-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes Qualcomm Arm64 DeviceTree fixes for v6.13 Revert the enablement of OTG support on primary and secondary USB Type-C controllers of X1 Elite, for now, as this broke support for USB hotplug. Disable the TPDM DCC device on SA8775P, as this is inaccessible per current firmware configuration. Also correct the PCIe "addr_space" region to enable larger BAR sizes. Also fix the address space of PCIe6a found in X1 Elite. * tag 'qcom-arm64-fixes-for-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: dts: qcom: sa8775p: fix the secure device bootup issue Revert "arm64: dts: qcom: x1e80100: enable OTG on USB-C controllers" Revert "arm64: dts: qcom: x1e80100-crd: enable otg on usb ports" arm64: dts: qcom: x1e80100: Fix up BAR space size for PCIe6a Revert "arm64: dts: qcom: x1e78100-t14s: enable otg on usb-c ports" arm64: dts: qcom: sa8775p: Fix the size of 'addr_space' regions Link: https://lore.kernel.org/r/20250103024945.4649-1-andersson@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
Peter Geis
|
3699f2c43e |
arm64: dts: rockchip: add hevc power domain clock to rk3328
There is a race condition at startup between disabling power domains not used and disabling clocks not used on the rk3328. When the clocks are disabled first, the hevc power domain fails to shut off leading to a splat of failures. Add the hevc core clock to the rk3328 power domain node to prevent this condition. rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 3-.... } 1087 jiffies s: 89 root: 0x8/. rcu: blocking rcu_node structures (internal RCU debug): Sending NMI from CPU 0 to CPUs 3: NMI backtrace for cpu 3 CPU: 3 UID: 0 PID: 86 Comm: kworker/3:3 Not tainted 6.12.0-rc5+ #53 Hardware name: Firefly ROC-RK3328-CC (DT) Workqueue: pm genpd_power_off_work_fn pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : regmap_unlock_spinlock+0x18/0x30 lr : regmap_read+0x60/0x88 sp : ffff800081123c00 x29: ffff800081123c00 x28: ffff2fa4c62cad80 x27: 0000000000000000 x26: ffffd74e6e660eb8 x25: ffff2fa4c62cae00 x24: 0000000000000040 x23: ffffd74e6d2f3ab8 x22: 0000000000000001 x21: ffff800081123c74 x20: 0000000000000000 x19: ffff2fa4c0412000 x18: 0000000000000000 x17: 77202c31203d2065 x16: 6c6469203a72656c x15: 6c6f72746e6f632d x14: 7265776f703a6e6f x13: 2063766568206e69 x12: 616d6f64202c3431 x11: 347830206f742030 x10: 3430303034783020 x9 : ffffd74e6c7369e0 x8 : 3030316666206e69 x7 : 205d383738353733 x6 : 332e31202020205b x5 : ffffd74e6c73fc88 x4 : ffffd74e6c73fcd4 x3 : ffffd74e6c740b40 x2 : ffff800080015484 x1 : 0000000000000000 x0 : ffff2fa4c0412000 Call trace: regmap_unlock_spinlock+0x18/0x30 rockchip_pmu_set_idle_request+0xac/0x2c0 rockchip_pd_power+0x144/0x5f8 rockchip_pd_power_off+0x1c/0x30 _genpd_power_off+0x9c/0x180 genpd_power_off.part.0.isra.0+0x130/0x2a8 genpd_power_off_work_fn+0x6c/0x98 process_one_work+0x170/0x3f0 worker_thread+0x290/0x4a8 kthread+0xec/0xf8 ret_from_fork+0x10/0x20 rockchip-pm-domain ff100000.syscon:power-controller: failed to get ack on domain 'hevc', val=0x88220 Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs") Signed-off-by: Peter Geis <pgwipeout@gmail.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/20241214224339.24674-1-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> |
||
Anton Kirilov
|
95147bb42b |
arm64: dts: rockchip: Fix the SD card detection on NanoPi R6C/R6S
Fix the SD card detection on FriendlyElec NanoPi R6C/R6S boards. Signed-off-by: Anton Kirilov <anton.kirilov@arm.com> Link: https://lore.kernel.org/r/20241219113145.483205-1-anton.kirilov@arm.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> |
||
Jie Gan
|
8a6442ec34 |
arm64: dts: qcom: sa8775p: fix the secure device bootup issue
The secure device(fused) cannot bootup with TPDM_DCC device. So disable it in DT. Fixes: 6596118ccdcd ("arm64: dts: qcom: Add coresight nodes for SA8775p") Signed-off-by: Jie Gan <quic_jiegan@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241219025216.3463527-1-quic_jiegan@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> |
||
Linus Torvalds
|
48f506ad0b |
soc: fixes for 6.13, part 2
Two more small fixes, correcting the cacheline size on Raspberry Pi 5 and fixing a logic mistake in the microchip mpfs firmware driver. -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmdnPmkACgkQYKtH/8kJ UicYsw//V/P84VpktPuSbZ4Uy41ns35DNmkSmZRGl5qTjTND6yjdl1ZkngzhHfC5 7yrq6OcHseErfUsv4OKpRYtsmSEl/hJcVKQTKP3m9qZ+TCpym0bmQc+pbnbNtwXI 1Um9Y5QL0yKw60elNW4ysJ+vUGlgMBIQG0gtz4aNu0BeLR2pEbs+WsodTm0z5Z8j AptHtB2Z1+ODM+uxJ44sVEd+uyC8cc3u8yWgMKNXVTPbI9xGm7IOoXb95rJGyFid WLgyU7ZDvPOMUwwbsp87bY0PUP8fQpMrxqnz51/TbzJiMs1U6Ikmg4imIPjAemh0 yb+8sH8M1mY8nV4efP/W5BEftGo1fc1yrzlEkb0Bgds10Ys4ra2JI/s5QJ7VOAY9 pZ/ajSiGjQ9elvd/es4KKbKwDnlccw77TaauKEkTyD6ZVmNZR7/s8IZ2/Zy//k3A 2bXP07GSgSH7Z5FUB3ExlDWRGoqjmzF9z8D7x3/MTL1pmWImXfDcclzAA5lj9yhM /LkploVbEcZ5ArV7oISu7GUfrxsxLNgobzEVUt2iRylw18YZJFFcvTlez5R0n4Zg fMiVW+fhpun5FJkGDL3B/BU2c+RUkL0RiIwElnUOBRXIrRyI4XjCTbw9vnPKZxHk XQkV+OZzlogq3TdtHqJ94Nwt3UKzSSMF4aAVOvcAzusHjMnyBdk= =UZKA -----END PGP SIGNATURE----- Merge tag 'soc-fixes-6.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "Two more small fixes, correcting the cacheline size on Raspberry Pi 5 and fixing a logic mistake in the microchip mpfs firmware driver" * tag 'soc-fixes-6.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: arm64: dts: broadcom: Fix L2 linesize for Raspberry Pi 5 firmware: microchip: fix UL_IAP lock check in mpfs_auto_update_state() |
||
Linus Torvalds
|
499551201b |
Fix a sparse warning in the arm64 signal code dealing with the user
shadow stack register, GCSPR_EL0. -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE5RElWfyWxS+3PLO2a9axLQDIXvEFAmdlufgACgkQa9axLQDI XvHS9Q//WmBcPgp99ZgmHwV4x9VZz4lBiZphBp2+WYNmYFjkEcNDggs8nWs+JwgR Y1isI5fLEuNYCqjoejtT5iPY3i9YAtiOtq8J7xnlZ35r3Ycur28f4C28ZxQnpHGH xaFO7deNTGhUkLvHaxIDxAyu8iHcJL+Q4XwuuTozedHPGwCHb5uyYHZB1fvYTrB0 x4yxJDBehsN9x/xQPNYlaaXpYG3i0as/1DQod7kKIDckxnGOOk1s1sTPPMTsOMAv W9xvUPUmzoRvn7nH1ErT7X3O8LzbACy6RDg1iGzdMINTuLDDM9n55i2tl0TToqqq 9h5IQ7ZSsPPixrPGarSZMhKnRKLHd0psFwfzhaWdPSGn4MHQInhkIP4vK05ycpxc E3AzbQMTb8ABVwW57XeJYnJJ28wY2QvQp0mm96xjSHfhYwafx4heTAM/4jzw5ZwC JsIbQsy603Ir7JhSV3rNozAUPI8GdQzXBYZ5PtW0AIbyJHAWP2R+/Q5kGK2IJd7a T5fzCLNSd0u7soY/4J856HYsDYw0SC0f6ua9BbaIC99vOlG9PhO/MJIkr+FsPeQq O3zH/xg/LGWQYudAoXYJhY6YuQ18mpdMw++/cNci2wWdhApf2sQLrhkO1Kz1numd WDDO13hyQZQMeulTeTrkS0teQmhuVeGvgb3vxLJzYi4OIEr8Iv4= =sJbw -----END PGP SIGNATURE----- Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Fix a sparse warning in the arm64 signal code dealing with the user shadow stack register, GCSPR_EL0" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64/signal: Silence sparse warning storing GCSPR_EL0 |
||
Arnd Bergmann
|
a31ffd6ed5 |
This pull request contains Broadcom ARM64-based SoCs Device Tree fixes
for 6.13, please pull the following: - Willow corrects the L2 cache line size on the Raspberry Pi 5 (2712) to the correct value of 64 bytes -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmdhy2AACgkQh9CWnEQH BwQFtBAAjcQLt3FMZlMaUD4ypPwwbSENG/gIO5YPQNaxYXpuSIKUu1xCfu8WsbdS gJqJ6LTGslvy3wN19wnPEblA0SdKafNsoFdbINbihQ+vkZalIqpqDYuoFTn8OoQ1 wO6VUT//LWFV/Xco/U1ELYKyu2Xr4fSnT5d87AE97V3ChrsftR2yLZuTuhLD30Fk gGPFlxqm/dMEjRu19kWfme2jsESQewjFeje6wT8QwpOIoDxtaZa9OrbBvZ+6es5i Oe10shORMR5igSeJyqneic3aH+We1D8LkCRStEbhais5PqZyRv88c52vjftPaBA+ FNvYCGZz8wNxbYY/G3v0EdakjzenqIvXb4OGL1c6rfXZ7SSaeieZuvAvpwtgPjma mJmE1BkFzatYQ/OXY63a+6ox9GMjMx2gPMtJTahPejW/Sp8EmpNFbWSHYDvw0bZD qQ07kr2uiTxpz/Oq7EaYN2SWdGHs06sThbrU3oI7/aAO6bfpG8cRDqEwgdbqZxKd RT9p6x3HpBBlq0/qV33vTBJQzw5D5Hm6DFG14QffSStiIewiOP4aegtQRQFxHoqr 5TiWcPooDV+NGQ/aLCh8aioUQ69WnyfqEYQhBGpH9jJKrnmb9BgW1dl7J6X0xE4P f4sKZYJAdltHyfSdXsC91Eb8xAKtGJDQ3luXycloQXh8koiyrBw= =24Xv -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmdloyMACgkQYKtH/8kJ Uie33A/+Lnq3Vd+gWGkng9fmvv/1B4aw7jqLm95aYYmm4ydX3iOadqqZRxlr2150 k3Utu0GygjkHlDPbMSZKFj8yPTu0o2L1aZTtDDpij3S/AGuogmypJlsLUQyDrDyq mFk+D8uxazu2tMjMHAL8nJ3GyOODw7rPuTp324MM5T8GC4FKeknicjHzN6KPlfsD L+4sWjlpGt1YQVb4uW2DEy7BAmPYpY5Pnl7Sh+YYzMa3ZIfru2PaFzdbqol/pbUZ Qusws8kcnoFLpT3KFpzNTYAwYKaMcNBRmoQLZZCAiH+GeT6FEK8B0mOwax0qDX8U Eiu3BmkCgjuYcIm1NQ8zZohQsKTtUt0FSu0auzU0t+Xq+jG5M9P6DqHMEFeBoi7T T9d0VsYB6BQ8240e8tGRNMAYuVLozPuL+BAdlF9ITrmw8JzthtVqZO/CRGiyODcg 3QvHZYArOMeZElHBHNdZEcPhnVHQ+cgdmL/4TZe2UHfqavG0Mhl4tnRU7e+nBjVN f7IuuySYuultBp3uwW8WueccICz0N99nmVaQ5HoqtKOfOrnGOoU77rewg6QkTYhp AIpFTGpwzE8y6/NOP7B3urNOTOYHe8Kiui2WfHt3M0cZdi+qlJn+3EtotCLcFHOY NLITkaGXeLoIumaZTvB4g7aiPFxXBbFVlINVjUwBzd2RGf5Yw9M= =tew5 -----END PGP SIGNATURE----- Merge tag 'arm-soc/for-6.13/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux into arm/fixes This pull request contains Broadcom ARM64-based SoCs Device Tree fixes for 6.13, please pull the following: - Willow corrects the L2 cache line size on the Raspberry Pi 5 (2712) to the correct value of 64 bytes * tag 'arm-soc/for-6.13/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux: arm64: dts: broadcom: Fix L2 linesize for Raspberry Pi 5 Link: https://lore.kernel.org/r/20241217190547.868744-1-florian.fainelli@broadcom.com Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
Mark Brown
|
926e862058 |
arm64/signal: Silence sparse warning storing GCSPR_EL0
We are seeing a sparse warning in gcs_restore_signal(): arch/arm64/kernel/signal.c:1054:9: sparse: sparse: cast removes address space '__user' of expression when storing the final GCSPR_EL0 value back into the register, caused by the fact that write_sysreg_s() casts the value it writes to a u64 which sparse sees as discarding the __userness of the pointer. Avoid this by treating the address as an integer, casting to a pointer only when using it to write to userspace. While we're at it also inline gcs_signal_cap_valid() into it's one user and make equivalent updates to gcs_signal_entry(). Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202412082005.OBJ0BbWs-lkp@intel.com/ Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20241214-arm64-gcs-signal-sparse-v3-1-5e8d18fffc0c@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Johan Hovold
|
7db0ba3e6e |
Revert "arm64: dts: qcom: x1e80100: enable OTG on USB-C controllers"
This reverts commit f042bc234c2e00764b8aa2c9e2f8177cdc63f664. A recent change enabling role switching for the x1e80100 USB-C controllers breaks UCSI and DisplayPort Alternate Mode when the controllers are in host mode: ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: PPM init failed, stop trying As enabling OTG mode currently breaks SuperSpeed hotplug and suspend, and with retimer (and orientation detection) support not even merged yet, let's revert at least until we have stable host mode in mainline. Fixes: f042bc234c2e ("arm64: dts: qcom: x1e80100: enable OTG on USB-C controllers") Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/all/hw2pdof4ajadjsjrb44f2q4cz4yh5qcqz5d3l7gjt2koycqs3k@xx5xvd26uyef Link: https://lore.kernel.org/lkml/Z1gbyXk-SktGjL6-@hovoldconsulting.com/ Cc: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20241210111444.26240-4-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> |
||
Johan Hovold
|
2e5e1a7ea6 |
Revert "arm64: dts: qcom: x1e80100-crd: enable otg on usb ports"
This reverts commit 2dd3250191bcfe93b0c9da46624af830310400a7. A recent change enabling OTG mode on the x1e81000 CRD breaks suspend. Specifically, the device hard resets during resume if suspended with all controllers in device mode (i.e. no USB device connected). The corresponding change on the T14s also led to SuperSpeed hotplugs not being detected. With retimer (and orientation detection) support not even merged yet, let's revert at least until we have stable host mode in mainline. Fixes: 2dd3250191bc ("arm64: dts: qcom: x1e80100-crd: enable otg on usb ports") Reported-by: Abel Vesa <abel.vesa@linaro.org> Cc: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20241210111444.26240-3-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> |
||
Oliver Upton
|
e96d8b80af |
KVM: arm64: Only apply PMCR_EL0.P to the guest range of counters
An important distinction from other registers affected by HPMN is that PMCR_EL0 only affects the guest range of counters, regardless of the EL from which it is accessed. Ensure that PMCR_EL0.P is always applied to 'guest' counters by manually computing the mask rather than deriving it from the current context. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20241217175611.3658290-1-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
Oliver Upton
|
d3ba35b69e |
KVM: arm64: nv: Reload PMU events upon MDCR_EL2.HPME change
MDCR_EL2.HPME is the 'global' enable bit for event counters reserved for EL2. Give the PMU a kick when it's changed to ensure events are reprogrammed before returning to the guest. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20241217175550.3658212-1-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
Oliver Upton
|
adf8623b3f |
KVM: arm64: Use KVM_REQ_RELOAD_PMU to handle PMCR_EL0.E change
Nested virt introduces yet another set of 'global' knobs for controlling event counters that are reserved for EL2 (i.e. >= HPMN). Get ready to share some plumbing with the NV controls by offloading counter reprogramming to KVM_REQ_RELOAD_PMU. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20241217175532.3658134-1-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
Oliver Upton
|
e22c369520 |
KVM: arm64: Add unified helper for reprogramming counters by mask
Having separate helpers for enabling/disabling counters provides the wrong abstraction, as the state of each counter needs to be evaluated independently and, in some cases, use a different global enable bit. Collapse the enable/disable accessors into a single, common helper that reconfigures every counter set in @mask, leaving the complexity of determining if an event is actually enabled in kvm_pmu_counter_is_enabled(). Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20241217175513.3658056-1-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
Quentin Perret
|
985bb51f17 |
KVM: arm64: Always check the state from hyp_ack_unshare()
There are multiple pKVM memory transitions where the state of a page is not cross-checked from the completer's PoV for performance reasons. For example, if a page is PKVM_PAGE_OWNED from the initiator's PoV, we should be guaranteed by construction that it is PKVM_NOPAGE for everybody else, hence allowing us to save a page-table lookup. When it was introduced, hyp_ack_unshare() followed that logic and bailed out without checking the PKVM_PAGE_SHARED_BORROWED state in the hypervisor's stage-1. This was correct as we could safely assume that all host-initiated shares were directed at the hypervisor at the time. But with the introduction of other types of shares (e.g. for FF-A or non-protected guests), it is now very much required to cross check this state to prevent the host from running __pkvm_host_unshare_hyp() on a page shared with TZ or a non-protected guest. Thankfully, if an attacker were to try this, the hyp_unmap() call from hyp_complete_unshare() would fail, hence causing to WARN() from __do_unshare() with the host lock held, which is fatal. But this is fragile at best, and can hardly be considered a security measure. Let's just do the right thing and always check the state from hyp_ack_unshare(). Signed-off-by: Quentin Perret <qperret@google.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20241128154406.602875-1-qperret@google.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
Willow Cunningham
|
058387d9c6 |
arm64: dts: broadcom: Fix L2 linesize for Raspberry Pi 5
Set the cache-line-size parameter of the L2 cache for each core to the correct value of 64 bytes. Previously, the L2 cache line size was incorrectly set to 128 bytes for the Broadcom BCM2712. This causes validation tests for the Performance Application Programming Interface (PAPI) tool to fail as they depend on sysfs accurately reporting cache line sizes. The correct value of 64 bytes is stated in the official documentation of the ARM Cortex A-72, which is linked in the comments of arm64/boot/dts/broadcom/bcm2712.dtsi as the source for cache-line-size. Fixes: faa3381267d0 ("arm64: dts: broadcom: Add minimal support for Raspberry Pi 5") Signed-off-by: Willow Cunningham <willow.e.cunningham@maine.edu> Link: https://lore.kernel.org/r/20241007212954.214724-1-willow.e.cunningham@maine.edu Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> |
||
Qiang Yu
|
fb8e7b33c2 |
arm64: dts: qcom: x1e80100: Fix up BAR space size for PCIe6a
As per memory map table, the region for PCIe6a is 64MByte. Hence, set the size of 32 bit non-prefetchable memory region beginning on address 0x70300000 as 0x3d00000 so that BAR space assigned to BAR registers can be allocated from 0x70300000 to 0x74000000. Fixes: 7af141850012 ("arm64: dts: qcom: x1e80100: Fix up BAR spaces") Cc: stable@vger.kernel.org Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20241113080508.3458849-1-quic_qianyu@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> |
||
Johan Hovold
|
1fb5cf0d16 |
Revert "arm64: dts: qcom: x1e78100-t14s: enable otg on usb-c ports"
This reverts commit 1a48dd7b9ac809d1bd0fd2fef509abba83433846. A recent change enabling OTG mode on the Lenovo ThinkPad T14s USB-C ports can break SuperSpeed device hotplugging. The host controller is enumerated, but the device is not: xhci-hcd xhci-hcd.5.auto: xHCI Host Controller xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 3 xhci-hcd xhci-hcd.5.auto: hcc params 0x0110ffc5 hci version 0x110 quirks 0x000080a000000810 xhci-hcd xhci-hcd.5.auto: irq 247, io mem 0x0a800000 xhci-hcd xhci-hcd.5.auto: xHCI Host Controller xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 4 xhci-hcd xhci-hcd.5.auto: Host supports USB 3.1 Enhanced SuperSpeed hub 3-0:1.0: USB hub found hub 3-0:1.0: 1 port detected hub 4-0:1.0: USB hub found hub 4-0:1.0: 1 port detected Once this happens on either of the two ports, no amount of disconnecting and reconnecting makes the SuperSpeed device be enumerated, while FullSpeed device enumeration still works. With retimer (and orientation detection) support not even merged yet, let's revert at least until we have stable host mode in mainline. Fixes: 1a48dd7b9ac8 ("arm64: dts: qcom: x1e78100-t14s: enable otg on usb-c ports") Cc: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20241206172402.20724-1-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> |
||
Linus Torvalds
|
f44d154d6e |
soc: fixes for 6.13
There are three small fixes for the soc tree: - A devicetee fix for the Arm Juno reference machine, so allow more interesting PCI configurations - A build fix for SCMI firmware on the NXP i.MX platform - A fix for a race condition in Arm FF-A firmware -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmdgNf4ACgkQYKtH/8kJ Uid99g/9Eve2yPqK+nAqlfFs20NE/cDvdaQ9n2Z+rU5igpvrqR62rBVG2v7AuFHZ w8Awl2iB57y1XdCxG8FE0wQ+TloiN+aLwgmbUh2st2fTjmPh6KgGq6jsGbvDli07 WrlH4PxxMm8axO2HwEWiSLsQBpeoqYvgO+6GDW5eXLtsbr6VuFNBoD6ExC/YVqsQ kCdHG+WrjA+rZyXjYZqlAknLaldLEplVPmh9riZEcdYh02QE5VXU53+ctUtYZENU VGM/638YAlnCANKYH9u5e8YmL2RgiLLNS63xSdO0krv/gCEor3txKvcG6Cie+76d n0bOu13kWdcJbrt0+wVR6ILCffAurhxZZ6L3Q+iSqJ0as/eBXeZtBKYyEl5w6vZf X32TkPmx3cvCTZG8Vs+0e4JlC/5wiPrPCTdQSStTckp7FDEs9sttEpeZWenYJNQY 7hVFj2Nx8SFv0JCB9N68CJB1KkhhRkAqNq6aKymTNJZLxAd72xJm3sOlDmOPRJ43 9j6LwQ6panUk49WNRklwuL0YajcX1jTS/MRHQfKtVCOfBD05A0BaQEDeAUeYfq2V rCFphvZn315fv6h1XLP0LkBTOJ0f+3X+0GcwtMUX8TC/AJXPnKHAuZKmujmVH8Uh mtfvVlUuvnw73LM/QlyAaG/D9Tj2wHtN2HNtTaGl6CY6zdeznRw= =+t0h -----END PGP SIGNATURE----- Merge tag 'soc-fixes-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "Three small fixes for the soc tree: - devicetee fix for the Arm Juno reference machine, to allow more interesting PCI configurations - build fix for SCMI firmware on the NXP i.MX platform - fix for a race condition in Arm FF-A firmware" * tag 'soc-fixes-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: arm64: dts: fvp: Update PCIe bus-range property firmware: arm_ffa: Fix the race around setting ffa_dev->properties firmware: arm_scmi: Fix i.MX build dependency |
||
Linus Torvalds
|
81576a9a27 |
ARM64:
* Fix confusion with implicitly-shifted MDCR_EL2 masks breaking SPE/TRBE initialization. * Align nested page table walker with the intended memory attribute combining rules of the architecture. * Prevent userspace from constraining the advertised ASID width, avoiding horrors of guest TLBIs not matching the intended context in hardware. * Don't leak references on LPIs when insertion into the translation cache fails. RISC-V: * Replace csr_write() with csr_set() for HVIEN PMU overflow bit. x86: * Cache CPUID.0xD XSTATE offsets+sizes during module init - On Intel's Emerald Rapids CPUID costs hundreds of cycles and there are a lot of leaves under 0xD. Getting rid of the CPUIDs during nested VM-Enter and VM-Exit is planned for the next release, for now just cache them: even on Skylake that is 40% faster. -----BEGIN PGP SIGNATURE----- iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmdcibgUHHBib256aW5p QHJlZGhhdC5jb20ACgkQv/vSX3jHroOQsgf+NwNdfNQ0V5vU7YNeVxyhkCyYvNiA njvBTd1Lwh7EDtJ2NLKzwHktH2ymQI8qykxKr/qY3Jxkow+vcvsK0LacAaJdIzGo jnMGxXxRCFpxdkNb1kDJk4Cd6GSSAxYwgPj3wj7whsMcVRjPlFcjuHf02bRUU0Gt yulzBOZJ/7QTquKSnwt1kZQ1i/mJ8wCh4vJArZqtcImrDSK7oh+BaQ44h+lNe8qa Xiw6Fw3tYXgHy5WlnUU/OyFs+bZbcVzPM75qYgdGIWSo0TdL69BeIw8S4K2Ri4eL EoEBigwAd8PiF16Q1wO4gXWcNwinMTs3LIftxYpENTHA5gnrS5hgWWDqHw== =4v2y -----END PGP SIGNATURE----- Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull kvm fixes from Paolo Bonzini: "ARM64: - Fix confusion with implicitly-shifted MDCR_EL2 masks breaking SPE/TRBE initialization - Align nested page table walker with the intended memory attribute combining rules of the architecture - Prevent userspace from constraining the advertised ASID width, avoiding horrors of guest TLBIs not matching the intended context in hardware - Don't leak references on LPIs when insertion into the translation cache fails RISC-V: - Replace csr_write() with csr_set() for HVIEN PMU overflow bit x86: - Cache CPUID.0xD XSTATE offsets+sizes during module init On Intel's Emerald Rapids CPUID costs hundreds of cycles and there are a lot of leaves under 0xD. Getting rid of the CPUIDs during nested VM-Enter and VM-Exit is planned for the next release, for now just cache them: even on Skylake that is 40% faster" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init RISC-V: KVM: Fix csr_write -> csr_set for HVIEN PMU overflow bit KVM: arm64: vgic-its: Add error handling in vgic_its_cache_translation KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden KVM: arm64: Fix S1/S2 combination when FWB==1 and S2 has Device memory type arm64: Fix usage of new shifted MDCR_EL2 values |
||
Kevin Brodsky
|
a3b4647e2f |
arm64: signal: Ensure signal delivery failure is recoverable
Commit eaf62ce1563b ("arm64/signal: Set up and restore the GCS context for signal handlers") introduced a potential failure point at the end of setup_return(). This is unfortunate as it is too late to deliver a SIGSEGV: if that SIGSEGV is handled, the subsequent sigreturn will end up returning to the original handler, which is not the intention (since we failed to deliver that signal). Make sure this does not happen by calling gcs_signal_entry() at the very beginning of setup_return(), and add a comment just after to discourage error cases being introduced from that point onwards. While at it, also take care of copy_siginfo_to_user(): since it may fail, we shouldn't be calling it after setup_return() either. Call it before setup_return() instead, and move the setting of X1/X2 inside setup_return() where it belongs (after the "point of no failure"). Background: the first part of setup_rt_frame(), including setup_sigframe(), has no impact on the execution of the interrupted thread. The signal frame is written to the stack, but the stack pointer remains unchanged. Failure at this stage can be recovered by a SIGSEGV handler, and sigreturn will restore the original context, at the point where the original signal occurred. On the other hand, once setup_return() has updated registers including SP, the thread's control flow has been modified and we must deliver the original signal. Fixes: eaf62ce1563b ("arm64/signal: Set up and restore the GCS context for signal handlers") Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Reviewed-by: Dave Martin <Dave.Martin@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20241210160940.2031997-1-kevin.brodsky@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Mark Rutland
|
65ac33bed8 |
arm64: stacktrace: Don't WARN when unwinding other tasks
The arm64 stacktrace code has a few error conditions where a WARN_ON_ONCE() is triggered before the stacktrace is terminated and an error is returned to the caller. The conditions shouldn't be triggered when unwinding the current task, but it is possible to trigger these when unwinding another task which is not blocked, as the stack of that task is concurrently modified. Kent reports that these warnings can be triggered while running filesystem tests on bcachefs, which calls the stacktrace code directly. To produce a meaningful stacktrace of another task, the task in question should be blocked, but the stacktrace code is expected to be robust to cases where it is not blocked. Note that this is purely about not unuduly scaring the user and/or crashing the kernel; stacktraces in such cases are meaningless and may leak kernel secrets from the stack of the task being unwound. Ideally we'd pin the task in a blocked state during the unwind, as we do for /proc/${PID}/wchan since commit: 42a20f86dc19f928 ("sched: Add wrapper for get_wchan() to keep task blocked") ... but a bunch of places don't do that, notably /proc/${PID}/stack, where we don't pin the task in a blocked state, but do restrict the output to privileged users since commit: f8a00cef17206ecd ("proc: restrict kernel stack dumps to root") ... and so it's possible to trigger these warnings accidentally, e.g. by reading /proc/*/stack (as root): | for n in $(seq 1 10); do | while true; do cat /proc/*/stack > /dev/null 2>&1; done & | done | ------------[ cut here ]------------ | WARNING: CPU: 3 PID: 166 at arch/arm64/kernel/stacktrace.c:207 arch_stack_walk+0x1c8/0x370 | Modules linked in: | CPU: 3 UID: 0 PID: 166 Comm: cat Not tainted 6.13.0-rc2-00003-g3dafa7a7925d #2 | Hardware name: linux,dummy-virt (DT) | pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : arch_stack_walk+0x1c8/0x370 | lr : arch_stack_walk+0x1b0/0x370 | sp : ffff800080773890 | x29: ffff800080773930 x28: fff0000005c44500 x27: fff00000058fa038 | x26: 000000007ffff000 x25: 0000000000000000 x24: 0000000000000000 | x23: ffffa35a8d9600ec x22: 0000000000000000 x21: fff00000043a33c0 | x20: ffff800080773970 x19: ffffa35a8d960168 x18: 0000000000000000 | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 | x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 | x8 : ffff8000807738e0 x7 : ffff8000806e3800 x6 : ffff8000806e3818 | x5 : ffff800080773920 x4 : ffff8000806e4000 x3 : ffff8000807738e0 | x2 : 0000000000000018 x1 : ffff8000806e3800 x0 : 0000000000000000 | Call trace: | arch_stack_walk+0x1c8/0x370 (P) | stack_trace_save_tsk+0x8c/0x108 | proc_pid_stack+0xb0/0x134 | proc_single_show+0x60/0x120 | seq_read_iter+0x104/0x438 | seq_read+0xf8/0x140 | vfs_read+0xc4/0x31c | ksys_read+0x70/0x108 | __arm64_sys_read+0x1c/0x28 | invoke_syscall+0x48/0x104 | el0_svc_common.constprop.0+0x40/0xe0 | do_el0_svc+0x1c/0x28 | el0_svc+0x30/0xcc | el0t_64_sync_handler+0x10c/0x138 | el0t_64_sync+0x198/0x19c | ---[ end trace 0000000000000000 ]--- Fix this by only warning when unwinding the current task. When unwinding another task the error conditions will be handled by returning an error without producing a warning. The two warnings in kunwind_next_frame_record_meta() were added recently as part of commit: c2c6b27b5aa14fa2 ("arm64: stacktrace: unwind exception boundaries") The warning when recovering the fgraph return address has changed form many times, but was originally introduced back in commit: 9f416319f40cd857 ("arm64: fix unwind_frame() for filtered out fn for function graph tracing") Fixes: c2c6b27b5aa1 ("arm64: stacktrace: unwind exception boundaries") Fixes: 9f416319f40c ("arm64: fix unwind_frame() for filtered out fn for function graph tracing") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reported-by: Kent Overstreet <kent.overstreet@linux.dev> Cc: Kees Cook <keescook@chromium.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20241211140704.2498712-3-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Mark Rutland
|
32ed120568 |
arm64: stacktrace: Skip reporting LR at exception boundaries
Aishwarya reports that warnings are sometimes seen when running the ftrace kselftests, e.g. | WARNING: CPU: 5 PID: 2066 at arch/arm64/kernel/stacktrace.c:141 arch_stack_walk+0x4a0/0x4c0 | Modules linked in: | CPU: 5 UID: 0 PID: 2066 Comm: ftracetest Not tainted 6.13.0-rc2 #2 | Hardware name: linux,dummy-virt (DT) | pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arch_stack_walk+0x4a0/0x4c0 | lr : arch_stack_walk+0x248/0x4c0 | sp : ffff800083643d20 | x29: ffff800083643dd0 x28: ffff00007b891400 x27: ffff00007b891928 | x26: 0000000000000001 x25: 00000000000000c0 x24: ffff800082f39d80 | x23: ffff80008003ee8c x22: ffff80008004baa8 x21: ffff8000800533e0 | x20: ffff800083643e10 x19: ffff80008003eec8 x18: 0000000000000000 | x17: 0000000000000000 x16: ffff800083640000 x15: 0000000000000000 | x14: 02a37a802bbb8a92 x13: 00000000000001a9 x12: 0000000000000001 | x11: ffff800082ffad60 x10: ffff800083643d20 x9 : ffff80008003eed0 | x8 : ffff80008004baa8 x7 : ffff800086f2be80 x6 : ffff0000057cf000 | x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800086f2b690 | x2 : ffff80008004baa8 x1 : ffff80008004baa8 x0 : ffff80008004baa8 | Call trace: | arch_stack_walk+0x4a0/0x4c0 (P) | arch_stack_walk+0x248/0x4c0 (L) | profile_pc+0x44/0x80 | profile_tick+0x50/0x80 (F) | tick_nohz_handler+0xcc/0x160 (F) | __hrtimer_run_queues+0x2ac/0x340 (F) | hrtimer_interrupt+0xf4/0x268 (F) | arch_timer_handler_virt+0x34/0x60 (F) | handle_percpu_devid_irq+0x88/0x220 (F) | generic_handle_domain_irq+0x34/0x60 (F) | gic_handle_irq+0x54/0x140 (F) | call_on_irq_stack+0x24/0x58 (F) | do_interrupt_handler+0x88/0x98 | el1_interrupt+0x34/0x68 (F) | el1h_64_irq_handler+0x18/0x28 | el1h_64_irq+0x6c/0x70 | queued_spin_lock_slowpath+0x78/0x460 (P) The warning in question is: WARN_ON_ONCE(state->common.pc == orig_pc)) ... in kunwind_recover_return_address(), which is triggered when return_to_handler() is encountered in the trace, but ftrace_graph_ret_addr() cannot find a corresponding original return address on the fgraph return stack. This happens because the stacktrace code encounters an exception boundary where the LR was not live at the time of the exception, but the LR happens to contain return_to_handler(); either because the task recently returned there, or due to unfortunate usage of the LR at a scratch register. In such cases attempts to recover the return address via ftrace_graph_ret_addr() may fail, triggering the WARN_ON_ONCE() above and aborting the unwind (hence the stacktrace terminating after reporting the PC at the time of the exception). Handling unreliable LR values in these cases is likely to require some larger rework, so for the moment avoid this problem by restoring the old behaviour of skipping the LR at exception boundaries, which the stacktrace code did prior to commit: c2c6b27b5aa14fa2 ("arm64: stacktrace: unwind exception boundaries") This commit is effectively a partial revert, keeping the structures and logic to explicitly identify exception boundaries while still skipping reporting of the LR. The logic to explicitly identify exception boundaries is still useful for general robustness and as a building block for future support for RELIABLE_STACKTRACE. Fixes: c2c6b27b5aa1 ("arm64: stacktrace: unwind exception boundaries") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20241211140704.2498712-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Paolo Bonzini
|
3154bddf8c |
KVM/arm64 fixes for 6.13, part #2
- Fix confusion with implicitly-shifted MDCR_EL2 masks breaking SPE/TRBE initialization - Align nested page table walker with the intended memory attribute combining rules of the architecture - Prevent userspace from constraining the advertised ASID width, avoiding horrors of guest TLBIs not matching the intended context in hardware - Don't leak references on LPIs when insertion into the translation cache fails -----BEGIN PGP SIGNATURE----- iI0EABYIADUWIQSNXHjWXuzMZutrKNKivnWIJHzdFgUCZ0+mZhccb2xpdmVyLnVw dG9uQGxpbnV4LmRldgAKCRCivnWIJHzdFuKcAQDnFcLru8MVor4zjloe25oPPeuW iBocGpgKwJMioHrAdwEAoq8v0eqfxrUpwr5KJ7iN9CTo9oANJYhVACC8jPHEowI= =fLPh -----END PGP SIGNATURE----- Merge tag 'kvmarm-fixes-6.13-2' of https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 6.13, part #2 - Fix confusion with implicitly-shifted MDCR_EL2 masks breaking SPE/TRBE initialization - Align nested page table walker with the intended memory attribute combining rules of the architecture - Prevent userspace from constraining the advertised ASID width, avoiding horrors of guest TLBIs not matching the intended context in hardware - Don't leak references on LPIs when insertion into the translation cache fails |
||
Arnd Bergmann
|
90386e1ba4 |
Armv8 Juno fix for v6.13
Just a single fix updating the PCIe bus address range to accommodate the full ECAM window of 256MB available on most of the recent versions of RevC FVP models. -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmdRh6oACgkQAEG6vDF+ 4piVWQ/6Akpv99sbqwa401L43kwdCnmubRXxO+IPFVPVAsVUPTO9OCPfohSixlAy JXgIW1lusN//J1y4UFIfMjcqCdUA0itFJHsWIYCLzwoaHo/B/IRZps0eTNiY1WF9 XZMEgkb9/6ccd8TAa66L88AIjr/VZQpDSqoVJ2Pe8txckjJDlftwRro/KJmuU6go /2rqfeNIgN2rRiqlPpMcsz3BktCcQ2hYOu1tGpX6zPr4fBg1epX/Zi5WiUZjm0RR VWqP+R5anf9iXpC37Wek51/ixEXm2I9NFYSTg1LNU/tI1xqGwReE8dLxmHHOJoWW bcGApJhwV8CQEgm0JzeKz62Qi/l4LbDGfU2irajtuwG6F2rF/2LD6U+EMsHLrqDN SnNedBSE7bclTEZv02X5SZfKf20LQbaTtMo74Y/uEoERd9/nVKR4bj28ZPc4olm8 klNQqpITlyJZ2xcLx1qs7kx9MK2ztYPmyzXHco7jByRDhfr0mWojXUfeEgWjnLQT 0xpicb31f+ewhLeKE9zC0RT2z15Sz7z49aXsbU43LxkneLNLBbJbyi3fOlTiSVqd BzjoQOKwzrBg0dz4H3yqEV17/9kSrtFOWnEtf3eS7j/wFI/VbvgIgtKHHEbBLWhR w8QShUzOWReI78lazjYEV6ZXPD2q0PZWhgHDWyNjW6uvrLoM/9o= =j1a9 -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmdXBxEACgkQYKtH/8kJ Uicc7A/8C0ACMtnzT/bx28j5XHofkhoq8VaCmdbX3H04r/EMKXypChO2I3R56FPx ydX8HefAdkiQOgGVdcHrZ+x8/vyCCXxSRqyjgb+Yt+GGzse6TN952Oz8NptCkW74 5v917V7Am9E0va1U9E1rpIhU+eCT6JzoD5xXK1d+0g52koZE4JtAv9DdS3Jjm/VV 3GpcdLsSdG1csrkhKVnApSsY/Q6Tv3+G9olJ7qWY1NnWU916JZD/fJRL2wTL60id uHr6ja0dqAo6A0+ztbEkhnv3ccOaPwDG9a/gORhDQf/TvLE7Ef/qAzHmUF8cJCv5 x2SHKL7lRyIb3Nn7RNq1PptPZw8FyCLprvuhrlDHa5LWO1Thj1iAlKrvJMTqYihy dzOKcRNZVmL9tX0xHW4RMDyl+P1rqsUhJOT5+/OWZRWPYV0AcwF0aquGqvrdaRR+ 30uX+KQ+otLzbKkyUtKOKGlhUWwg8zIXFCjO1TqhBUgxrzZLnY5aFmqNGB1IkA5A QmQH+oFWxktiEBjZ6KnCDUwEsDbfuT9l0+qhuVLXFDwBV2XShIZQYewrrymBYeA8 I+I5hd4J+9zsVKLU3+Nj/+GavD0M4bGdF46NRWixheGga4La2MkCNNMC6dLqm8f1 UQIlLu7LQ67xUDvqIdbyI8iUnyIsJhMpgTD/AglmUsRqBVIJKgY= =enl+ -----END PGP SIGNATURE----- Merge tag 'juno-fix-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes Armv8 Juno fix for v6.13 Just a single fix updating the PCIe bus address range to accommodate the full ECAM window of 256MB available on most of the recent versions of RevC FVP models. * tag 'juno-fix-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: arm64: dts: fvp: Update PCIe bus-range property Link: https://lore.kernel.org/r/20241205114302.708433-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
Wei Fang
|
c5b8d2c370 |
arm64: dts: imx95: correct the address length of netcmix_blk_ctrl
The netc_blk_ctrl is controlled by the imx95-blk-ctl clock driver and provides relevant clock configurations for NETC, SAI and MQS. Its address length should be 8 bytes instead of 0x1000. Fixes: 7764fef26ea9 ("arm64: dts: imx95: Add NETCMIX block control support") Signed-off-by: Wei Fang <wei.fang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> |
||
Frank Li
|
c70812cb28 |
arm64: dts: imx8-ss-audio: add fallback compatible string fsl,imx6ull-esai for esai
The ESAI of i.MX8QM is the same as i.MX6ULL. So add fsl,imx6ull-esai for esai. Signed-off-by: Frank Li <Frank.Li@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Fixes: adf7ea48ce05 ("ASoC: dt-bindings: fsl-esai: allow fsl,imx8qm-esai fallback to fsl,imx6ull-esai") Signed-off-by: Shawn Guo <shawnguo@kernel.org> |
||
Linus Torvalds
|
f3ddc438a2 |
arm64 fixes for 6.13-rc2:
- MTE/hugetlbfs: - Set VM_MTE_ALLOWED in the arch code and remove it from the core code for hugetlbfs mappings - Fix copy_highpage() warning when the source is a huge page but not MTE tagged, taking the wrong small page path - drivers/virt/coco: - Add the pKVM and Arm CCA drivers under the arm64 maintainership - Fix the pkvm driver to fall back to ioremap() (and warn) if the MMIO_GUARD hypercall fails - Keep the Arm CCA driver default 'n' rather than 'm' - A series of fixes for the arm64 ptrace() implementation, potentially leading to the kernel consuming uninitialised stack variables when PTRACE_SETREGSET is invoked with a length of 0 - Fix zone_dma_limit calculation when RAM starts below 4GB and ZONE_DMA is capped to this limit - Fix early boot warning with CONFIG_DEBUG_VIRTUAL=y triggered by a call to page_to_phys() (from patch_map()) which checks pfn_valid() before vmemmap has been set up - Do not clobber bits 15:8 of the ASID used for TTBR1_EL1 and TLBI ops when the kernel assumes 8-bit ASIDs but running under a hypervisor on a system that implements 16-bit ASIDs (found running Linux under Parallels on Apple M4) - ACPI/IORT: Add PMCG platform information for HiSilicon HIP09A as it is using the same SMMU PMCG as HIP09 and suffers from the same errata - Add GCS to cpucap_is_possible(), missed in the recent merge -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE5RElWfyWxS+3PLO2a9axLQDIXvEFAmdTQW4ACgkQa9axLQDI XvGLUQ/+MEiCFytDsSIQsGMaCpRCcrNX3dzhgekjTSiS+iPRTGjhHPMxAgnKgtim U6MIdxItS5bvFKWQC/VmA3V+EtMy+9uwfQOy7MbG+wIzwlg48Pn2MjgmheSxhftO 0x+lUB+5ELU9KxL0KV+WNCE5l/iBpzcSG+Uj3iqc5rPuYHxa8npekd/KVba42zGY QqZ75yCW5EQwyuSZve8SSMqyHNgZHNgwzhs0aRr3ZwccqE9eMKpcEv5wxbl6raGB Qr4HG+c3w4rQFBsj+9Zs/f5G45uZ+pM55aAVLSihhCdq51/oXXPajOWMP3tV6ke+ hHXm4buxgIR2CWeCXp8n/H7S3OQIj4uFqmaFIGxv0+0OTemUBIEg8kAtqVcnxSXY hk00J5yMurDik1hhud21ZHaJaELwWAwpisVCjYBblUGOoH9uH062gb02CGWv3lSe hrzYohhi7IAPzDzK339Q3HVr5PZOGagoBS2B1ptX2f6rrPITIuB2rW+lzNDuuBSX twHcdZzmSgl2zmFu4D3ql5Oa2ewLMiOn0Z96Esz5y9f74jbLh9ynU7QyRZM0MioS V6te7HanJ17zMK6S2thj7qsewqV6N4lcWd7M5ZclK29F8qcW5OWuKn5njFQT7K4s QDI0+1uYaSMcWoDAXNVXZf3oKMJDy1LeG+UXGyP5b0AQJrqYrWQ= =zZ4I -----END PGP SIGNATURE----- Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: "Nothing major, some left-overs from the recent merging window (MTE, coco) and some newly found issues like the ptrace() ones. - MTE/hugetlbfs: - Set VM_MTE_ALLOWED in the arch code and remove it from the core code for hugetlbfs mappings - Fix copy_highpage() warning when the source is a huge page but not MTE tagged, taking the wrong small page path - drivers/virt/coco: - Add the pKVM and Arm CCA drivers under the arm64 maintainership - Fix the pkvm driver to fall back to ioremap() (and warn) if the MMIO_GUARD hypercall fails - Keep the Arm CCA driver default 'n' rather than 'm' - A series of fixes for the arm64 ptrace() implementation, potentially leading to the kernel consuming uninitialised stack variables when PTRACE_SETREGSET is invoked with a length of 0 - Fix zone_dma_limit calculation when RAM starts below 4GB and ZONE_DMA is capped to this limit - Fix early boot warning with CONFIG_DEBUG_VIRTUAL=y triggered by a call to page_to_phys() (from patch_map()) which checks pfn_valid() before vmemmap has been set up - Do not clobber bits 15:8 of the ASID used for TTBR1_EL1 and TLBI ops when the kernel assumes 8-bit ASIDs but running under a hypervisor on a system that implements 16-bit ASIDs (found running Linux under Parallels on Apple M4) - ACPI/IORT: Add PMCG platform information for HiSilicon HIP09A as it is using the same SMMU PMCG as HIP09 and suffers from the same errata - Add GCS to cpucap_is_possible(), missed in the recent merge" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: ptrace: fix partial SETREGSET for NT_ARM_GCS arm64: ptrace: fix partial SETREGSET for NT_ARM_POE arm64: ptrace: fix partial SETREGSET for NT_ARM_FPMR arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL arm64: cpufeature: Add GCS to cpucap_is_possible() coco: virt: arm64: Do not enable cca guest driver by default arm64: mte: Fix copy_highpage() warning on hugetlb folios arm64: Ensure bits ASID[15:8] are masked out when the kernel uses 8-bit ASIDs ACPI/IORT: Add PMCG platform information for HiSilicon HIP09A MAINTAINERS: Add CCA and pKVM CoCO guest support to the ARM64 entry drivers/virt: pkvm: Don't fail ioremap() call if MMIO_GUARD fails arm64: patching: avoid early page_to_phys() arm64: mm: Fix zone_dma_limit calculation arm64: mte: set VM_MTE_ALLOWED for hugetlbfs at correct place |
||
Mark Rutland
|
d60624f72d |
arm64: ptrace: fix partial SETREGSET for NT_ARM_GCS
Currently gcs_set() doesn't initialize the temporary 'user_gcs' variable, and a SETREGSET call with a length of 0, 8, or 16 will leave some portion of this uninitialized. Consequently some arbitrary uninitialized values may be written back to the relevant fields in task struct, potentially leaking up to 192 bits of memory from the kernel stack. The read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. As gcs_set() rejects cases where user_gcs::features_enabled has bits set other than PR_SHADOW_STACK_SUPPORTED_STATUS_MASK, a SETREGSET call with a length of zero will randomly succeed or fail depending on the value of the uninitialized value, it isn't possible to leak the full 192 bits. With a length of 8 or 16, user_gcs::features_enabled can be initialized to an accepted value, making it practical to leak 128 or 64 bits. Fix this by initializing the temporary value before copying the regset from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length or partial write, the existing contents of the fields which are not written to will be retained. To ensure that the extraction and insertion of fields is consistent across the GETREGSET and SETREGSET calls, new task_gcs_to_user() and task_gcs_from_user() helpers are added, matching the style of pac_address_keys_to_user() and pac_address_keys_from_user(). Before this patch: | # ./gcs-test | Attempting to write NT_ARM_GCS::user_gcs = { | .features_enabled = 0x0000000000000000, | .features_locked = 0x0000000000000000, | .gcspr_el0 = 0x900d900d900d900d, | } | SETREGSET(nt=0x410, len=24) wrote 24 bytes | | Attempting to read NT_ARM_GCS::user_gcs | GETREGSET(nt=0x410, len=24) read 24 bytes | Read NT_ARM_GCS::user_gcs = { | .features_enabled = 0x0000000000000000, | .features_locked = 0x0000000000000000, | .gcspr_el0 = 0x900d900d900d900d, | } | | Attempting partial write NT_ARM_GCS::user_gcs = { | .features_enabled = 0x0000000000000000, | .features_locked = 0x1de7ec7edbadc0de, | .gcspr_el0 = 0x1de7ec7edbadc0de, | } | SETREGSET(nt=0x410, len=8) wrote 8 bytes | | Attempting to read NT_ARM_GCS::user_gcs | GETREGSET(nt=0x410, len=24) read 24 bytes | Read NT_ARM_GCS::user_gcs = { | .features_enabled = 0x0000000000000000, | .features_locked = 0x000000000093e780, | .gcspr_el0 = 0xffff800083a63d50, | } After this patch: | # ./gcs-test | Attempting to write NT_ARM_GCS::user_gcs = { | .features_enabled = 0x0000000000000000, | .features_locked = 0x0000000000000000, | .gcspr_el0 = 0x900d900d900d900d, | } | SETREGSET(nt=0x410, len=24) wrote 24 bytes | | Attempting to read NT_ARM_GCS::user_gcs | GETREGSET(nt=0x410, len=24) read 24 bytes | Read NT_ARM_GCS::user_gcs = { | .features_enabled = 0x0000000000000000, | .features_locked = 0x0000000000000000, | .gcspr_el0 = 0x900d900d900d900d, | } | | Attempting partial write NT_ARM_GCS::user_gcs = { | .features_enabled = 0x0000000000000000, | .features_locked = 0x1de7ec7edbadc0de, | .gcspr_el0 = 0x1de7ec7edbadc0de, | } | SETREGSET(nt=0x410, len=8) wrote 8 bytes | | Attempting to read NT_ARM_GCS::user_gcs | GETREGSET(nt=0x410, len=24) read 24 bytes | Read NT_ARM_GCS::user_gcs = { | .features_enabled = 0x0000000000000000, | .features_locked = 0x0000000000000000, | .gcspr_el0 = 0x900d900d900d900d, | } Fixes: 7ec3b57cb29f ("arm64/ptrace: Expose GCS via ptrace and core files") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20241205121655.1824269-5-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Mark Rutland
|
594bfc4947 |
arm64: ptrace: fix partial SETREGSET for NT_ARM_POE
Currently poe_set() doesn't initialize the temporary 'ctrl' variable, and a SETREGSET call with a length of zero will leave this uninitialized. Consequently an arbitrary value will be written back to target->thread.por_el0, potentially leaking up to 64 bits of memory from the kernel stack. The read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. Fix this by initializing the temporary value before copying the regset from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing contents of POR_EL1 will be retained. Before this patch: | # ./poe-test | Attempting to write NT_ARM_POE::por_el0 = 0x900d900d900d900d | SETREGSET(nt=0x40f, len=8) wrote 8 bytes | | Attempting to read NT_ARM_POE::por_el0 | GETREGSET(nt=0x40f, len=8) read 8 bytes | Read NT_ARM_POE::por_el0 = 0x900d900d900d900d | | Attempting to write NT_ARM_POE (zero length) | SETREGSET(nt=0x40f, len=0) wrote 0 bytes | | Attempting to read NT_ARM_POE::por_el0 | GETREGSET(nt=0x40f, len=8) read 8 bytes | Read NT_ARM_POE::por_el0 = 0xffff8000839c3d50 After this patch: | # ./poe-test | Attempting to write NT_ARM_POE::por_el0 = 0x900d900d900d900d | SETREGSET(nt=0x40f, len=8) wrote 8 bytes | | Attempting to read NT_ARM_POE::por_el0 | GETREGSET(nt=0x40f, len=8) read 8 bytes | Read NT_ARM_POE::por_el0 = 0x900d900d900d900d | | Attempting to write NT_ARM_POE (zero length) | SETREGSET(nt=0x40f, len=0) wrote 0 bytes | | Attempting to read NT_ARM_POE::por_el0 | GETREGSET(nt=0x40f, len=8) read 8 bytes | Read NT_ARM_POE::por_el0 = 0x900d900d900d900d Fixes: 175198199262 ("arm64/ptrace: add support for FEAT_POE") Cc: <stable@vger.kernel.org> # 6.12.x Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Joey Gouly <joey.gouly@arm.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20241205121655.1824269-4-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Mark Rutland
|
f5d7129184 |
arm64: ptrace: fix partial SETREGSET for NT_ARM_FPMR
Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable, and a SETREGSET call with a length of zero will leave this uninitialized. Consequently an arbitrary value will be written back to target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from the kernel stack. The read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. Fix this by initializing the temporary value before copying the regset from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing contents of FPMR will be retained. Before this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0xffff800083963d50 After this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d Fixes: 4035c22ef7d4 ("arm64/ptrace: Expose FPMR via ptrace") Cc: <stable@vger.kernel.org> # 6.9.x Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20241205121655.1824269-3-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Mark Rutland
|
ca62d90085 |
arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL
Currently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl' variable, and a SETREGSET call with a length of zero will leave this uninitialized. Consequently tagged_addr_ctrl_set() will consume an arbitrary value, potentially leaking up to 64 bits of memory from the kernel stack. The read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and rejects other values, a partial SETREGSET attempt will randomly succeed or fail depending on the value of the uninitialized value, and the exposure is significantly limited. Fix this by initializing the temporary value before copying the regset from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing value of the tagged address ctrl will be retained. The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the user_aarch64_view used by a native AArch64 task to manipulate another native AArch64 task. As get_tagged_addr_ctrl() only returns an error value when called for a compat task, tagged_addr_ctrl_get() and tagged_addr_ctrl_set() should never observe an error value from get_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that such an error would be unexpected, and error handlnig is not missing in either case. Fixes: 2200aa7154cb ("arm64: mte: ptrace: Add NT_ARM_TAGGED_ADDR_CTRL regset") Cc: <stable@vger.kernel.org> # 5.10.x Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20241205121655.1824269-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Robin Murphy
|
f00b53f161 |
arm64: cpufeature: Add GCS to cpucap_is_possible()
Since system_supports_gcs() ends up referring to cpucap_is_possible(), teach the latter about GCS for consistency with similar features. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/416c7369fcdce4ebb2a8f12daae234507be27e38.1733406275.git.robin.murphy@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Catalin Marinas
|
cf3b16dae4 |
arm64: mte: Fix copy_highpage() warning on hugetlb folios
Commit 25c17c4b55de ("hugetlb: arm64: add mte support") improved the copy_highpage() function to update the tags in the destination hugetlb folio. However, when the source folio isn't tagged, the code takes the non-hugetlb path where try_page_mte_tagging() warns as the destination is a hugetlb folio: WARNING: CPU: 0 PID: 363 at arch/arm64/include/asm/mte.h:58 copy_highpage+0x1d4/0x2d8 [...] pc : copy_highpage+0x1d4/0x2d8 lr : copy_highpage+0x78/0x2d8 [...] Call trace: copy_highpage+0x1d4/0x2d8 (P) copy_highpage+0x78/0x2d8 (L) copy_user_highpage+0x20/0x48 copy_user_large_folio+0x1bc/0x268 hugetlb_wp+0x190/0x860 hugetlb_fault+0xa28/0xc10 handle_mm_fault+0x2a0/0x2c0 do_page_fault+0x12c/0x578 do_mem_abort+0x4c/0xa8 el0_da+0x44/0xb0 el0t_64_sync_handler+0xc4/0x138 el0t_64_sync+0x198/0x1a0 Change the check for the tagged status of the source folio so that it does not fall through the non-hugetlb case. In addition, only perform the copy (for the full folio) if the source page is the folio head and warn if the destination folio is already tagged, for symmetry with the non-hugetlb case. Fixes: 25c17c4b55de ("hugetlb: arm64: add mte support") Reported-by: Sasha Levin <sashal@kernel.org> Cc: Yang Shi <yang@os.amperecomputing.com> Cc: David Hildenbrand <david@redhat.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/Z0STR6VLt2MCalnY@sashalap Link: https://lore.kernel.org/r/20241204175004.906754-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Catalin Marinas
|
c0900d15d3 |
arm64: Ensure bits ASID[15:8] are masked out when the kernel uses 8-bit ASIDs
Linux currently sets the TCR_EL1.AS bit unconditionally during CPU bring-up. On an 8-bit ASID CPU, this is RES0 and ignored, otherwise 16-bit ASIDs are enabled. However, if running in a VM and the hypervisor reports 8-bit ASIDs (ID_AA64MMFR0_EL1.ASIDBits == 0) on a 16-bit ASIDs CPU, Linux uses bits 8 to 63 as a generation number for tracking old process ASIDs. The bottom 8 bits of this generation end up being written to TTBR1_EL1 and also used for the ASID-based TLBI operations as the upper 8 bits of the ASID. Following an ASID roll-over event we can have threads of the same application with the same 8-bit ASID but different generation numbers running on separate CPUs. Both TLB caching and the TLBI operations will end up using different actual 16-bit ASIDs for the same process. A similar scenario can happen in a big.LITTLE configuration if the boot CPU only uses 8-bit ASIDs while secondary CPUs have 16-bit ASIDs. Ensure that the ASID generation is only tracked by bits 16 and up, leaving bits 15:8 as 0 if the kernel uses 8-bit ASIDs. Note that clearing TCR_EL1.AS is not sufficient since the architecture requires that the top 8 bits of the ASID passed to TLBI instructions are 0 rather than ignored in such configuration. Cc: stable@vger.kernel.org Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: James Morse <james.morse@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20241203151941.353796-1-catalin.marinas@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Aneesh Kumar K.V (Arm)
|
4f776d81bf |
arm64: dts: fvp: Update PCIe bus-range property
These days, the Fixed Virtual Platforms(FVP) Base RevC model supports more PCI devices. Update the max bus number so that Linux can enumerate them correctly. Without this, the kernel throws the below error while booting with the default hierarchy | pci_bus 0000:01: busn_res: [bus 01] end is updated to 01 | pci_bus 0000:02: busn_res: can not insert [bus 02-01] under | [bus 00-01] (conflicts with (null) [bus 00-01]) | pci_bus 0000:02: busn_res: [bus 02-01] end is updated to 02 | pci_bus 0000:02: busn_res: can not insert [bus 02] under | [bus 00-01] (conflicts with (null) [bus 00-01]) | pci_bus 0000:03: busn_res: can not insert [bus 03-01] under | [bus 00-01] (conflicts with (null) [bus 00-01]) | pci_bus 0000:03: busn_res: [bus 03-01] end is updated to 03 | pci_bus 0000:03: busn_res: can not insert [bus 03] under | [bus 00-01] (conflicts with (null) [bus 00-01]) | pci_bus 0000:04: busn_res: can not insert [bus 04-01] under | [bus 00-01] (conflicts with (null) [bus 00-01]) | pci_bus 0000:04: busn_res: [bus 04-01] end is updated to 04 | pci_bus 0000:04: busn_res: can not insert [bus 04] under | [bus 00-01] (conflicts with (null) [bus 00-01]) | pci 0000:00:01.0: BAR 14: assigned [mem 0x50000000-0x500fffff] | pci-host-generic 40000000.pci: ECAM at [mem 0x40000000-0x4fffffff] | for [bus 00-01] The change is using 0xff as max bus number because the ECAM window is 256MB in size. Below is the lspci output with and without the change: without fix =========== | 00:00.0 Host bridge: ARM Device 00ba (rev 01) | 00:01.0 PCI bridge: ARM Device 0def | 00:02.0 PCI bridge: ARM Device 0def | 00:03.0 PCI bridge: ARM Device 0def | 00:04.0 PCI bridge: ARM Device 0def | 00:1e.0 Unassigned class [ff00]: ARM Device ff80 | 00:1e.1 Unassigned class [ff00]: ARM Device ff80 | 00:1f.0 SATA controller: Device 0abc:aced (rev 01) | 01:00.0 SATA controller: Device 0abc:aced (rev 01) with fix ======== | 00:00.0 Host bridge: ARM Device 00ba (rev 01) | 00:01.0 PCI bridge: ARM Device 0def | 00:02.0 PCI bridge: ARM Device 0def | 00:03.0 PCI bridge: ARM Device 0def | 00:04.0 PCI bridge: ARM Device 0def | 00:1e.0 Unassigned class [ff00]: ARM Device ff80 | 00:1e.1 Unassigned class [ff00]: ARM Device ff80 | 00:1f.0 SATA controller: Device 0abc:aced (rev 01) | 01:00.0 SATA controller: Device 0abc:aced (rev 01) | 02:00.0 Unassigned class [ff00]: ARM Device ff80 | 02:00.4 Unassigned class [ff00]: ARM Device ff80 | 03:00.0 PCI bridge: ARM Device 0def | 04:00.0 PCI bridge: ARM Device 0def | 04:01.0 PCI bridge: ARM Device 0def | 04:02.0 PCI bridge: ARM Device 0def | 05:00.0 SATA controller: Device 0abc:aced (rev 01) | 06:00.0 Unassigned class [ff00]: ARM Device ff80 | 06:00.7 Unassigned class [ff00]: ARM Device ff80 | 07:00.0 Unassigned class [ff00]: ARM Device ff80 | 07:00.3 Unassigned class [ff00]: ARM Device ff80 | 08:00.0 Unassigned class [ff00]: ARM Device ff80 | 08:00.1 Unassigned class [ff00]: ARM Device ff80 Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: Rob Herring <robh@kernel.org> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org> Cc: Conor Dooley <conor+dt@kernel.org> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Message-Id: <20241128152543.1821878-1-aneesh.kumar@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> |
||
Keisuke Nishimura
|
be7e611274 |
KVM: arm64: vgic-its: Add error handling in vgic_its_cache_translation
The return value of xa_store() needs to be checked. This fix adds an error handling path that resolves the kref inconsistency on failure. As suggested by Oliver Upton, this function does not return the error code intentionally because the translation cache is best effort. Fixes: 8201d1028caa ("KVM: arm64: vgic-its: Maintain a translation cache per ITS") Signed-off-by: Keisuke Nishimura <keisuke.nishimura@inria.fr> Suggested-by: Oliver Upton <oliver.upton@linux.dev> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20241130144952.23729-1-keisuke.nishimura@inria.fr Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
Marc Zyngier
|
03c7527e97 |
KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden
Catalin reports that a hypervisor lying to a guest about the size of the ASID field may result in unexpected issues: - if the underlying HW does only supports 8 bit ASIDs, the ASID field in a TLBI VAE1* operation is only 8 bits, and the HW will ignore the other 8 bits - if on the contrary the HW is 16 bit capable, the ASID field in the same TLBI operation is always 16 bits, irrespective of the value of TCR_ELx.AS. This could lead to missed invalidations if the guest was lead to assume that the HW had 8 bit ASIDs while they really are 16 bit wide. In order to avoid any potential disaster that would be hard to debug, prenent the migration between a host with 8 bit ASIDs to one with wider ASIDs (the converse was obviously always forbidden). This is also consistent with what we already do for VMIDs. If it becomes absolutely mandatory to support such a migration path in the future, we will have to trap and emulate all TLBIs, something that nobody should look forward to. Fixes: d5a32b60dc18 ("KVM: arm64: Allow userspace to change ID_AA64MMFR{0-2}_EL1") Reported-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Oliver Upton <oliver.upton@linux.dev> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20241203190236.505759-1-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev> |
||
Mark Rutland
|
8d09e2d569 |
arm64: patching: avoid early page_to_phys()
When arm64 is configured with CONFIG_DEBUG_VIRTUAL=y, a warning is printed from the patching code because patch_map(), e.g. | ------------[ cut here ]------------ | WARNING: CPU: 0 PID: 0 at arch/arm64/kernel/patching.c:45 patch_map.constprop.0+0x120/0xd00 | CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.13.0-rc1-00002-ge1a5d6c6be55 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 800003c5 (Nzcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : patch_map.constprop.0+0x120/0xd00 | lr : patch_map.constprop.0+0x120/0xd00 | sp : ffffa9bb312a79a0 | x29: ffffa9bb312a79a0 x28: 0000000000000001 x27: 0000000000000001 | x26: 0000000000000000 x25: 0000000000000000 x24: 00000000000402e8 | x23: ffffa9bb2c94c1c8 x22: ffffa9bb2c94c000 x21: ffffa9bb222e883c | x20: 0000000000000002 x19: ffffc1ffc100ba40 x18: ffffa9bb2cf0f21c | x17: 0000000000000006 x16: 0000000000000000 x15: 0000000000000004 | x14: 1ffff5376625b4ac x13: ffff753766a67fb8 x12: ffff753766919cd1 | x11: 0000000000000003 x10: 1ffff5376625b4c3 x9 : 1ffff5376625b4af | x8 : ffff753766254f0a x7 : 0000000041b58ab3 x6 : ffff753766254f18 | x5 : ffffa9bb312d9bc0 x4 : 0000000000000000 x3 : ffffa9bb29bd90e4 | x2 : 0000000000000002 x1 : ffffa9bb312d9bc0 x0 : 0000000000000000 | Call trace: | patch_map.constprop.0+0x120/0xd00 (P) | patch_map.constprop.0+0x120/0xd00 (L) | __aarch64_insn_write+0xa8/0x120 | aarch64_insn_patch_text_nosync+0x4c/0xb8 | arch_jump_label_transform_queue+0x7c/0x100 | jump_label_update+0x154/0x460 | static_key_enable_cpuslocked+0x1d8/0x280 | static_key_enable+0x2c/0x48 | early_randomize_kstack_offset+0x104/0x168 | do_early_param+0xe4/0x148 | parse_args+0x3a4/0x838 | parse_early_options+0x50/0x68 | parse_early_param+0x58/0xe0 | setup_arch+0x78/0x1f0 | start_kernel+0xa0/0x530 | __primary_switched+0x8c/0xa0 | irq event stamp: 0 | hardirqs last enabled at (0): [<0000000000000000>] 0x0 | hardirqs last disabled at (0): [<0000000000000000>] 0x0 | softirqs last enabled at (0): [<0000000000000000>] 0x0 | softirqs last disabled at (0): [<0000000000000000>] 0x0 | ---[ end trace 0000000000000000 ]--- The warning has been produced since commit: 3e25d5a49f99b75b ("asm-generic: add an optional pfn_valid check to page_to_phys") ... which added a pfn_valid() check into page_to_phys(), and at this point in boot pfn_valid() will always return false because the vmemmap has not yet been initialized and there are no valid mem_sections yet. Before that commit, the arithmetic performed by page_to_phys() would give the expected physical address, though it is somewhat dubious to use vmemmap addresses before the vmemmap has been initialized. Aside from kernel image addresses, all executable code should be allocated from execmem (where all allocations will fall within the vmalloc area), and so there's no need for the fallback case when CONFIG_EXECMEM=n. Simplify patch_map() accordingly, directly converting kernel image addresses and removing the redundant fallback case. Fixes: 3e25d5a49f99 ("asm-generic: add an optional pfn_valid check to page_to_phys") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Christoph Hellwig <hch@lst.de> Cc: Mike Rapoport <rppt@kernel.org> Cc: Thomas Huth <thuth@redhat.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20241202170359.1475019-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Yang Shi
|
56a708742a |
arm64: mm: Fix zone_dma_limit calculation
Commit ba0fb44aed47 ("dma-mapping: replace zone_dma_bits by zone_dma_limit") and subsequent patches changed how zone_dma_limit is calculated to allow a reduced ZONE_DMA even when RAM starts above 4GB. Commit 122c234ef4e1 ("arm64: mm: keep low RAM dma zone") further fixed this to ensure ZONE_DMA remains below U32_MAX if RAM starts below 4GB, especially on platforms that do not have IORT or DT description of the device DMA ranges. While zone boundaries calculation was fixed by the latter commit, zone_dma_limit, used to determine the GFP_DMA flag in the core code, was not updated. This results in excessive use of GFP_DMA and unnecessary ZONE_DMA allocations on some platforms. Update zone_dma_limit to match the actual upper bound of ZONE_DMA. Fixes: ba0fb44aed47 ("dma-mapping: replace zone_dma_bits by zone_dma_limit") Cc: <stable@vger.kernel.org> # 6.12.x Reported-by: Yutang Jiang <jiangyutang@os.amperecomputing.com> Tested-by: Yutang Jiang <jiangyutang@os.amperecomputing.com> Signed-off-by: Yang Shi <yang@os.amperecomputing.com> Link: https://lore.kernel.org/r/20241125171650.77424-1-yang@os.amperecomputing.com [catalin.marinas@arm.com: some tweaking of the commit log] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
FUKAUMI Naoki
|
2ddd93481b |
arm64: dts: rockchip: rename rfkill label for Radxa ROCK 5B
on ROCK 5B, there is no PCIe slot, instead there is a M.2 slot. rfkill pin is not exclusive to PCIe devices, there is SDIO Wi-Fi devices. rename rfkill label from "rfkill-pcie-wlan" to "rfkill-m2-wlan", it matches with rfkill-bt. Fixes: 82d40b141a4c ("arm64: dts: rockchip: add rfkill node for M.2 Key E WiFi on rock-5b") Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Fixes: 82d40b141a4c ("arm64: dts: rockchip: add rfkill node for M.2 Key E WiFi on rock-5b") Link: https://lore.kernel.org/r/20241128120631.37458-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> |
||
Chukun Pan
|
8b9c12757f |
arm64: dts: rockchip: add reset-names for combphy on rk3568
The reset-names of combphy are missing, add it. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Fixes: fd3ac6e80497 ("dt-bindings: phy: rockchip: rk3588 has two reset lines") Link: https://lore.kernel.org/r/20241122073006.99309-1-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de> |
||
Peter Zijlstra
|
cdd30ebb1b |
module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo) to __section("foo")") and for the same reason, it is not desired for the namespace argument to be a macro expansion itself. Scripted using git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file; do awk -i inplace ' /^#define EXPORT_SYMBOL_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /^#define MODULE_IMPORT_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /MODULE_IMPORT_NS/ { $0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g"); } /EXPORT_SYMBOL_NS/ { if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) { if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ && $0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ && $0 !~ /^my/) { getline line; gsub(/[[:space:]]*\\$/, ""); gsub(/[[:space:]]/, "", line); $0 = $0 " " line; } $0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/, "\\1(\\2, \"\\3\")", "g"); } } { print }' $file; done Requested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc Acked-by: Greg KH <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
||
Yang Shi
|
49ccf2c3ca |
arm64: mte: set VM_MTE_ALLOWED for hugetlbfs at correct place
The commit 5de195060b2e ("mm: resolve faulty mmap_region() error path behaviour") moved vm flags validation before fop->mmap for file mappings. But when commit 25c17c4b55de ("hugetlb: arm64: add mte support") was rebased on top of it, the hugetlbfs part was missed. Mmapping hugetlbfs file may not have MAP_HUGETLB set. Fixes: 25c17c4b55de ("hugetlb: arm64: add mte support") Signed-off-by: Yang Shi <yang@os.amperecomputing.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20241119200914.1145249-1-yang@os.amperecomputing.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> |
||
Manivannan Sadhasivam
|
e60b14f47d |
arm64: dts: qcom: sa8775p: Fix the size of 'addr_space' regions
For both the controller instances, size of the 'addr_space' region should be 0x1fe00000 as per the hardware memory layout. Otherwise, endpoint drivers cannot request even reasonable BAR size of 1MB. Cc: stable@vger.kernel.org # 6.11 Fixes: c5f5de8434ec ("arm64: dts: qcom: sa8775p: Add ep pcie1 controller node") Fixes: 1924f5518224 ("arm64: dts: qcom: sa8775p: Add ep pcie0 controller node") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241128145147.145618-1-manivannan.sadhasivam@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> |
||
Linus Torvalds
|
a14bf463e7 |
i2c-for-6.13-rc1-part3
core: add of based component probing Some devices are designed and manufactured with some components having multiple drop-in replacement options. These components are often connected to the mainboard via ribbon cables, having the same signals and pin assignments across all options. These may include the display panel and touchscreen on laptops and tablets, and the trackpad on laptops. Sometimes which component option is used in a particular device can be detected by some firmware provided identifier, other times that information is not available, and the kernel has to try to probe each device. Instead of a delicate dance between drivers and device tree quirks, this change introduces a simple I2C component probe function. For a given class of devices on the same I2C bus, it will go through all of them, doing a simple I2C read transfer and see which one of them responds. It will then enable the device that responds. -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmdMOCwACgkQFA3kzBSg KbaLWQ//e+29c9Trh+Typ6YCknuCFmM12xNUEPgce93EldERZjfCsdlHEchJnjEe RX5Mw+UxT7NqFUD6G2YQQw35LMj/PDws4Q/q3OwAvurj2PqoKEGIbdTxUEbGrLtT aYRUjGoqjPk3gAkqfKEQp8X8bvqKJfQ/xeXcZyy7Ij8xPU1LC/W6So4vpZA7oZkZ UfwrUXu2NM/DKfLATeSH3vnlBrrpco9BdjImDanP8BpuYHQ0aNt7IToDytd3/rLZ WKQPbHqVzzBUHm8Tf+DTyeVtII/ID078z+RW7htPrzPtzhVu2DN56w3z7/+EsVIy XKb1PiJo5HlFev4gxhIcUgf8L5JYE8MyU8eeRWAcDObiBYVcSP34P7Xoykczjuq9 22IFNSdaqMVdigo9v4p7U99fVjoi3oUqIVsSb2HkmND8bPw3+jtyq1GxTFvTeOw8 EVJGuGjYrPiko26zNgK/WZaumpB+fsH7uRioSb1ejlSQk0BcNv4YqjYaMx9aT7Xj +zF7luuxpkWTkPCjk57GX55K/BFzkA9jhJdKqjImBS+Q9Rn3k5bHyRdNPUDIeWs0 Yl5dhg6QbLHyuPC2R/hJiV6X4uFloH9+Oh99T3lLzcVNc2mllPQDN9F4I8q5nWB8 Eq5U95fnegfdVkiWnbNCnTCux/mypm35Gx46BffTiAJL2U9pSIE= =MAxU -----END PGP SIGNATURE----- Merge tag 'i2c-for-6.13-rc1-part3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c component probing support from Wolfram Sang: "Add OF component probing. Some devices are designed and manufactured with some components having multiple drop-in replacement options. These components are often connected to the mainboard via ribbon cables, having the same signals and pin assignments across all options. These may include the display panel and touchscreen on laptops and tablets, and the trackpad on laptops. Sometimes which component option is used in a particular device can be detected by some firmware provided identifier, other times that information is not available, and the kernel has to try to probe each device. Instead of a delicate dance between drivers and device tree quirks, this change introduces a simple I2C component probe function. For a given class of devices on the same I2C bus, it will go through all of them, doing a simple I2C read transfer and see which one of them responds. It will then enable the device that responds" * tag 'i2c-for-6.13-rc1-part3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: MAINTAINERS: fix typo in I2C OF COMPONENT PROBER of: base: Document prefix argument for of_get_next_child_with_prefix() i2c: Fix whitespace style issue arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail platform/chrome: Introduce device tree hardware prober i2c: of-prober: Add GPIO support to simple helpers i2c: of-prober: Add simple helpers for regulator support i2c: Introduce OF component probe function of: base: Add for_each_child_of_node_with_prefix() of: dynamic: Add of_changeset_update_prop_string |