summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2022-04-08mips: DEC: honor CONFIG_MIPS_FP_SUPPORT=nRandy Dunlap2-4/+5
[ Upstream commit 97bf0395c226907e1a9b908511a35192bf1e09bb ] Include the DECstation interrupt handler in opting out of FPU support. Fixes a linker error: mips-linux-ld: arch/mips/dec/int-handler.o: in function `fpu': (.text+0x148): undefined reference to `handle_fpe_int' Fixes: 183b40f992c8 ("MIPS: Allow FP support to be disabled") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Paul Burton <paulburton@kernel.org> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Maciej W. Rozycki <macro@orcam.me.uk> Cc: linux-mips@vger.kernel.org Acked-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08KVM: x86/emulator: Defer not-present segment check in ↵Hou Wenlong1-5/+9
__load_segment_descriptor() [ Upstream commit ca85f002258fdac3762c57d12d5e6e401b6a41af ] Per Intel's SDM on the "Instruction Set Reference", when loading segment descriptor, not-present segment check should be after all type and privilege checks. But the emulator checks it first, then #NP is triggered instead of #GP if privilege fails and segment is not present. Put not-present segment check after type and privilege checks in __load_segment_descriptor(). Fixes: 38ba30ba51a00 (KVM: x86 emulator: Emulate task switch in emulator.c) Reviewed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com> Message-Id: <52573c01d369f506cadcf7233812427cf7db81a7.1644292363.git.houwenlong.hwl@antgroup.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08KVM: x86: Fix emulation in writing cr8Zhenzhong Duan1-4/+1
[ Upstream commit f66af9f222f08d5b11ea41c1bd6c07a0f12daa07 ] In emulation of writing to cr8, one of the lowest four bits in TPR[3:0] is kept. According to Intel SDM 10.8.6.1(baremetal scenario): "APIC.TPR[bits 7:4] = CR8[bits 3:0], APIC.TPR[bits 3:0] = 0"; and SDM 28.3(use TPR shadow): "MOV to CR8. The instruction stores bits 3:0 of its source operand into bits 7:4 of VTPR; the remainder of VTPR (bits 3:0 and bits 31:8) are cleared."; and AMD's APM 16.6.4: "Task Priority Sub-class (TPS)-Bits 3 : 0. The TPS field indicates the current sub-priority to be used when arbitrating lowest-priority messages. This field is written with zero when TPR is written using the architectural CR8 register."; so in KVM emulated scenario, clear TPR[3:0] to make a consistent behavior as in other scenarios. This doesn't impact evaluation and delivery of pending virtual interrupts because processor does not use the processor-priority sub-class to determine which interrupts to delivery and which to inhibit. Sub-class is used by hardware to arbitrate lowest priority interrupts, but KVM just does a round-robin style delivery. Fixes: b93463aa59d6 ("KVM: Accelerated apic support") Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Sean Christopherson <seanjc@google.com> Message-Id: <20220210094506.20181-1-zhenzhong.duan@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08powerpc/Makefile: Don't pass -mcpu=powerpc64 when building 32-bitMichael Ellerman1-1/+1
[ Upstream commit 2863dd2db23e0407f6c50b8ba5c0e55abef894f1 ] When CONFIG_GENERIC_CPU=y (true for all our defconfigs) we pass -mcpu=powerpc64 to the compiler, even when we're building a 32-bit kernel. This happens because we have an ifdef CONFIG_PPC_BOOK3S_64/else block in the Makefile that was written before 32-bit supported GENERIC_CPU. Prior to that the else block only applied to 64-bit Book3E. The GCC man page says -mcpu=powerpc64 "[specifies] a pure ... 64-bit big endian PowerPC ... architecture machine [type], with an appropriate, generic processor model assumed for scheduling purposes." It's unclear how that interacts with -m32, which we are also passing, although obviously -m32 is taking precedence in some sense, as the 32-bit kernel only contains 32-bit instructions. This was noticed by inspection, not via any bug reports, but it does affect code generation. Comparing before/after code generation, there are some changes to instruction scheduling, and the after case (with -mcpu=powerpc64 removed) the compiler seems more keen to use r8. Fix it by making the else case only apply to Book3E 64, which excludes 32-bit. Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220215112858.304779-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08powerpc/mm/numa: skip NUMA_NO_NODE onlining in parse_numa_properties()Daniel Henrique Barboza1-1/+3
[ Upstream commit 749ed4a20657bcea66a6e082ca3dc0d228cbec80 ] Executing node_set_online() when nid = NUMA_NO_NODE results in an undefined behavior. node_set_online() will call node_set_state(), into __node_set(), into set_bit(), and since NUMA_NO_NODE is -1 we'll end up doing a negative shift operation inside arch/powerpc/include/asm/bitops.h. This potential UB was detected running a kernel with CONFIG_UBSAN. The behavior was introduced by commit 10f78fd0dabb ("powerpc/numa: Fix a regression on memoryless node 0"), where the check for nid > 0 was removed to fix a problem that was happening with nid = 0, but the result is that now we're trying to online NUMA_NO_NODE nids as well. Checking for nid >= 0 will allow node 0 to be onlined while avoiding this UB with NUMA_NO_NODE. Fixes: 10f78fd0dabb ("powerpc/numa: Fix a regression on memoryless node 0") Reported-by: Ping Fang <pifang@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220224182312.1012527-1-danielhb413@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08bpf, arm64: Feed byte-offset into bpf line infoHou Tao1-0/+5
[ Upstream commit dda7596c109fc382876118627e29db7607cde35d ] insn_to_jit_off passed to bpf_prog_fill_jited_linfo() is calculated in instruction granularity instead of bytes granularity, but BPF line info requires byte offset. bpf_prog_fill_jited_linfo() will be the last user of ctx.offset before it is freed, so convert the offset into byte-offset before calling into bpf_prog_fill_jited_linfo() in order to fix the line info dump on arm64. Fixes: 37ab566c178d ("bpf: arm64: Enable arm64 jit to provide bpf_line_info") Suggested-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220226121906.5709-3-houtao1@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08bpf, arm64: Call build_prologue() first in first JIT passHou Tao1-5/+8
[ Upstream commit 68e4f238b0e9d3670a1612ad900a6e98b2b3f7dd ] BPF line info needs ctx->offset to be the instruction offset in the whole JITed image instead of the body itself, so also call build_prologue() first in first JIT pass. Fixes: 37ab566c178d ("bpf: arm64: Enable arm64 jit to provide bpf_line_info") Signed-off-by: Hou Tao <houtao1@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220226121906.5709-2-houtao1@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08powerpc/perf: Don't use perf_hw_context for trace IMC PMUAthira Rajeev1-1/+5
[ Upstream commit 0198322379c25215b2778482bf1221743a76e2b5 ] Trace IMC (In-Memory collection counters) in powerpc is useful for application level profiling. For trace_imc, presently task context (task_ctx_nr) is set to perf_hw_context. But perf_hw_context should only be used for CPU PMU. See commit 26657848502b ("perf/core: Verify we have a single perf_hw_context PMU"). So for trace_imc, even though it is per thread PMU, it is preferred to use sw_context in order to be able to do application level monitoring. Hence change the task_ctx_nr to use perf_sw_context. Fixes: 012ae244845f ("powerpc/perf: Trace imc PMU functions") Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> [mpe: Update subject & incorporate notes into change log, reflow comment] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220202041837.65968-1-atrajeev@linux.vnet.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08KVM: PPC: Book3S HV: Check return value of kvmppc_radix_initFabiano Rosas1-1/+4
[ Upstream commit 69ab6ac380a00244575de02c406dcb9491bf3368 ] The return of the function is being shadowed by the call to kvmppc_uvmem_init. Fixes: ca9f4942670c ("KVM: PPC: Book3S HV: Support for running secure guests") Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220125155735.1018683-2-farosas@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08powerpc: dts: t1040rdb: fix ports names for Seville Ethernet switchMaxim Kiselev2-4/+34
[ Upstream commit 5ebb74749202a25da4b3cc2eb15470225a05527c ] On board rev A, the network interface labels for the switch ports written on the front panel are different than on rev B and later. This patch fixes network interface names for the switch ports according to labels that are written on the front panel of the board rev B. They start from ETH3 and end at ETH10. This patch also introduces a separate device tree for rev A. The main device tree is supposed to cover rev B and later. Fixes: e69eb0824d8c ("powerpc: dts: t1040rdb: add ports for Seville Ethernet switch") Signed-off-by: Maxim Kiselev <bigunclemax@gmail.com> Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220121091447.3412907-1-bigunclemax@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08KVM: PPC: Fix vmx/vsx mixup in mmio emulationFabiano Rosas1-2/+2
[ Upstream commit b99234b918c6e36b9aa0a5b2981e86b6bd11f8e2 ] The MMIO emulation code for vector instructions is duplicated between VSX and VMX. When emulating VMX we should check the VMX copy size instead of the VSX one. Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction ...") Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220125215655.1026224-3-farosas@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08ARM: configs: multi_v5_defconfig: re-enable CONFIG_V4L_PLATFORM_DRIVERSAndre Przywara1-0/+1
[ Upstream commit f5eb04d7a0e419d61f784de3ced708259ddb71d7 ] Commit 06b93644f4d1 ("media: Kconfig: add an option to filter in/out platform drivers") introduced CONFIG_MEDIA_PLATFORM_SUPPORT, to allow more fine grained control over the inclusion of certain Kconfig files. multi_v5_defconfig was selecting some drivers described in drivers/media/platform/Kconfig, which now wasn't included anymore. Explicitly set the new symbol in multi_v5_defconfig to bring those drivers back. This enables some new V4L2 and VIDEOBUF2 features, but as modules only. Fixes: 06b93644f4d1 ("media: Kconfig: add an option to filter in/out platform drivers") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Link: https://lore.kernel.org/r/20220317183043.948432-3-andre.przywara@arm.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08m68k: coldfire/device.c: only build for MCF_EDMA when h/w macros are definedRandy Dunlap1-3/+3
[ Upstream commit e6e1e7b19fa132d23d09c465942aab4c110d3da9 ] When CONFIG_MCF_EDMA is set (due to COMPILE_TEST, not due to CONFIG_M5441x), coldfire/device.c has compile errors due to missing MCFEDMA_* symbols. In the .config file that was provided, CONFIG_M5206=y, not CONFIG_M5441x, so <asm/m5441xsim.h> is not included in coldfire/device.c. Only build the MCF_EDMA code in coldfire/device.c if the MCFEDMA_* hardware macros are defined. Fixes these build errors: ../arch/m68k/coldfire/device.c:512:35: error: 'MCFEDMA_BASE' undeclared here (not in a function); did you mean 'MCFDMA_BASE1'? 512 | .start = MCFEDMA_BASE, ../arch/m68k/coldfire/device.c:513:50: error: 'MCFEDMA_SIZE' undeclared here (not in a function) 513 | .end = MCFEDMA_BASE + MCFEDMA_SIZE - 1, ../arch/m68k/coldfire/device.c:517:35: error: 'MCFEDMA_IRQ_INTR0' undeclared here (not in a function) 517 | .start = MCFEDMA_IRQ_INTR0, ../arch/m68k/coldfire/device.c:523:35: error: 'MCFEDMA_IRQ_INTR16' undeclared here (not in a function) 523 | .start = MCFEDMA_IRQ_INTR16, ../arch/m68k/coldfire/device.c:529:35: error: 'MCFEDMA_IRQ_INTR56' undeclared here (not in a function) 529 | .start = MCFEDMA_IRQ_INTR56, ../arch/m68k/coldfire/device.c:535:35: error: 'MCFEDMA_IRQ_ERR' undeclared here (not in a function) 535 | .start = MCFEDMA_IRQ_ERR, Fixes: d7e9d01ac292 ("m68k: add ColdFire mcf5441x eDMA platform support") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Link: lore.kernel.org/r/202203030252.P752DK46-lkp@intel.com Cc: Angelo Dureghello <angelo@sysam.it> Cc: Greg Ungerer <gerg@kernel.org> Cc: Greg Ungerer <gerg@linux-m68k.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: linux-m68k@lists.linux-m68k.org Cc: uclinux-dev@uclinux.org Signed-off-by: Greg Ungerer <gerg@linux-m68k.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08arm64: dts: rockchip: Fix SDIO regulator supply properties on rk3399-fireflyRob Herring1-2/+2
[ Upstream commit 37cbd3c522869247ed4525b5042ff4c6a276c813 ] A label reference without brackets is a path string, not a phandle as intended. Add the missing brackets. Fixes: a5002c41c383 ("arm64: dts: rockchip: add WiFi module support for Firefly-RK3399") Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220304202559.317749-1-robh@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08arm64: dts: broadcom: Fix sata nodenameFrank Wunderlich1-1/+1
[ Upstream commit 55927cb44db43a57699fa652e2437a91620385dc ] After converting ahci-platform txt binding to yaml nodename is reported as not matching the standard: arch/arm64/boot/dts/broadcom/northstar2/ns2-svk.dt.yaml: ahci@663f2000: $nodename:0: 'ahci@663f2000' does not match '^sata(@.*)?$' Fix it to match binding. Fixes: ac9aae00f0fc ("arm64: dts: Add SATA3 AHCI and SATA3 PHY DT nodes for NS2") Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08arm64: dts: ns2: Fix spi-cpol and spi-cpha propertyKuldeep Singh1-4/+4
[ Upstream commit c953c764e505428f59ffe6afb1c73b89b5b1ac35 ] Broadcom ns2 platform has spi-cpol and spi-cpho properties set incorrectly. As per spi-slave-peripheral-prop.yaml, these properties are of flag or boolean type and not integer type. Fix the values. Fixes: d69dbd9f41a7c (arm64: dts: Add ARM PL022 SPI DT nodes for NS2) Signed-off-by: Kuldeep Singh <singh.kuldeep87k@gmail.com> CC: Ray Jui <rjui@broadcom.com> CC: Scott Branden <sbranden@broadcom.com> CC: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08uaccess: fix nios2 and microblaze get_user_8()Arnd Bergmann2-19/+25
[ Upstream commit a97b693c3712f040c5802f32b2d685352e08cefa ] These two architectures implement 8-byte get_user() through a memcpy() into a four-byte variable, which won't fit. Use a temporary 64-bit variable instead here, and use a double cast the way that risc-v and openrisc do to avoid compile-time warnings. Fixes: 6a090e97972d ("arch/microblaze: support get_user() of size 8 bytes") Fixes: 5ccc6af5e88e ("nios2: Memory management") Reviewed-by: Christoph Hellwig <hch@lst.de> Acked-by: Dinh Nguyen <dinguyen@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08ARM: dts: imx: Add missing LVDS decoder on M53MenloMarek Vasut1-2/+27
[ Upstream commit 0c6f71176ea43d6f4003a4d57f7bb518c5ad6145 ] The M53Menlo display unit uses an LVDS-to-DPI bridge, TI DS90CF364A. Describe this bridge in DT, otherwise the DT incorrectly describes DPI panel attached directly to LVDS source. Fixes: 716be61d1869 ("ARM: dts: imx53: Add Menlosystems M53 board") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08ARM: dts: sun8i: v3s: Move the csi1 block to follow address orderPaul Kocialkowski1-11/+11
[ Upstream commit c4af51698c4fb4fc683f2ac67f482cdf9ba2cd13 ] The csi1 block node was mistakenly added before the gic node, although its address comes after the gic's. Move the node to its correct position. Fixes: 90e048101fa1 ("ARM: dts: sun8i: V3/V3s/S3/S3L: add CSI1 device node") Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220205185429.2278860-2-paul.kocialkowski@bootlin.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08arm64: dts: qcom: sm8150: Correct TCS configuration for apps rscMaulik Shah1-3/+3
[ Upstream commit 17ac8af678b6da6a8f1df7da8ebf2c5198741827 ] Correct the TCS config by updating the number of TCSes for each type. Cc: devicetree@vger.kernel.org Fixes: d8cf9372b654 ("arm64: dts: qcom: sm8150: Add apps shared nodes") Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1641749107-31979-2-git-send-email-quic_mkshah@quicinc.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08arm64: dts: qcom: sdm845: fix microphone bias properties and valuesDavid Heidelberg1-4/+4
[ Upstream commit 625c24460dbbc3b6c9a148c0a30f0830893fc909 ] replace millivolt with correct microvolt and adjust value to the minimal value allowed by documentation. Found with `make qcom/sdm845-oneplus-fajita.dtb`. Fixes: arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: codec@1: 'qcom,micbias1-microvolt' is a required property From schema: Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: codec@1: 'qcom,micbias2-microvolt' is a required property From schema: Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: codec@1: 'qcom,micbias3-microvolt' is a required property From schema: Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: codec@1: 'qcom,micbias4-microvolt' is a required property From schema: Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: codec@1: 'qcom,micbias1-millivolt', 'qcom,micbias2-millivolt', 'qcom,micbias3-millivolt', 'qcom,micbias4-millivolt' do not match any of the regexes: '^.*@[0-9a-f]+$', 'pinctrl-[0-9]+' Fixes: 27ca1de07dc3 ("arm64: dts: qcom: sdm845: add slimbus nodes") Signed-off-by: David Heidelberg <david@ixit.cz> Tested-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211213195105.114596-1-david@ixit.cz Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08ARM: dts: qcom: ipq4019: fix sleep clockPavel Kubelun1-1/+2
[ Upstream commit 3d7e7980993d2c1ae42d3d314040fc2de6a9c45f ] It seems like sleep_clk was copied from ipq806x. Fix ipq40xx sleep_clk to the value QSDK defines. Link: https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?id=d92ec59973484acc86dd24b67f10f8911b4b4b7d Link: https://patchwork.kernel.org/comment/22721613/ Fixes: bec6ba4cdf2a ("qcom: ipq4019: Add basic board/dts support for IPQ4019 SoC") Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org> (clock-output-names) Signed-off-by: Pavel Kubelun <be.dissent@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> (removed clock rename) Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211220170352.34591-1-chunkeey@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08perf/x86/intel/pt: Fix address filter config for 32-bit kernelAdrian Hunter1-1/+1
[ Upstream commit e5524bf1047eb3b3f3f33b5f59897ba67b3ade87 ] Change from shifting 'unsigned long' to 'u64' to prevent the config bits being lost on a 32-bit kernel. Fixes: eadf48cab4b6b0 ("perf/x86/intel/pt: Add support for address range filtering in PT") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20220131072453.2839535-5-adrian.hunter@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08clocksource/drivers/timer-ti-dm: Fix regression from errata i940 fixDrew Fustini2-7/+6
[ Upstream commit bceaae3bac0ce27c549bb050336d8d08abc2ee54 ] The existing fix for errata i940 causes a conflict for IPU2 which is using timer 3 and 4. From arch/arm/boot/dts/dra7-ipu-dsp-common.dtsi: &ipu2 { mboxes = <&mailbox6 &mbox_ipu2_ipc3x>; ti,timers = <&timer3>; ti,watchdog-timers = <&timer4>, <&timer9>; }; The conflict was noticed when booting mainline on the BeagleBoard X15 which has a TI AM5728 SoC: remoteproc remoteproc1: 55020000.ipu is available remoteproc remoteproc1: powering up 55020000.ipu remoteproc remoteproc1: Booting fw image dra7-ipu2-fw.xem4 omap-rproc 55020000.ipu: could not get timer platform device omap-rproc 55020000.ipu: omap_rproc_enable_timers failed: -19 remoteproc remoteproc1: can't start rproc 55020000.ipu: -19 This change modifies the errata fix to instead use timer 15 and 16 which resolves the timer conflict. It does not appear to introduce any latency regression. Results from cyclictest with original errata fix using dmtimer 3 and 4: # cyclictest --mlockall --smp --priority=80 --interval=200 --distance=0 policy: fifo: loadavg: 0.02 0.03 0.05 T: 0 ( 1449) P:80 I:200 C: 800368 Min: 0 Act: 32 Avg: 22 Max: 128 T: 1 ( 1450) P:80 I:200 C: 800301 Min: 0 Act: 12 Avg: 23 Max: 70 The results after the change to dmtimer 15 and 16: # cyclictest --mlockall --smp --priority=80 --interval=200 --distance=0 policy: fifo: loadavg: 0.36 0.19 0.07 T: 0 ( 1711) P:80 I:200 C: 759599 Min: 0 Act: 6 Avg: 22 Max: 108 T: 1 ( 1712) P:80 I:200 C: 759539 Min: 0 Act: 19 Avg: 23 Max: 79 Fixes: 25de4ce5ed02 ("clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940") Link: https://lore.kernel.org/linux-omap/YfWsG0p6to3IJuvE@x1/ Suggested-by: Suman Anna <s-anna@ti.com> Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Drew Fustini <dfustini@baylibre.com> Link: https://lore.kernel.org/r/20220204053503.1409162-1-dfustini@baylibre.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08arm64/mm: avoid fixmap race condition when create pud mappingJianyong Wu1-0/+9
[ Upstream commit ee017ee353506fcec58e481673e4331ff198a80e ] The 'fixmap' is a global resource and is used recursively by create pud mapping(), leading to a potential race condition in the presence of a concurrent call to alloc_init_pud(): kernel_init thread virtio-mem workqueue thread ================== =========================== alloc_init_pud(...) alloc_init_pud(...) pudp = pud_set_fixmap_offset(...) pudp = pud_set_fixmap_offset(...) READ_ONCE(*pudp) pud_clear_fixmap(...) READ_ONCE(*pudp) // CRASH! As kernel may sleep during creating pud mapping, introduce a mutex lock to serialise use of the fixmap entries by alloc_init_pud(). However, there is no need for locking in early boot stage and it doesn't work well with KASLR enabled when early boot. So, enable lock when system_state doesn't equal to "SYSTEM_BOOTING". Signed-off-by: Jianyong Wu <jianyong.wu@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Fixes: f4710445458c ("arm64: mm: use fixmap when creating page tables") Link: https://lore.kernel.org/r/20220201114400.56885-1-jianyong.wu@arm.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08xtensa: fix xtensa_wsr always writing 0Max Filippov1-2/+2
commit a3d0245c58f962ee99d4440ea0eaf45fb7f5a5cc upstream. The commit cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr") replaced 'WSR' macro in the function xtensa_wsr with 'xtensa_set_sr', but variable 'v' in the xtensa_set_sr body shadowed the argument 'v' passed to it, resulting in wrong value written to debug registers. Fix that by removing intermediate variable from the xtensa_set_sr macro body. Cc: stable@vger.kernel.org Fixes: cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr") Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08xtensa: fix stop_machine_cpuslocked call in patch_textMax Filippov1-1/+1
commit f406f2d03e07afc199dd8cf501f361dde6be8a69 upstream. patch_text must invoke patch_text_stop_machine on all online CPUs, but it calls stop_machine_cpuslocked with NULL cpumask. As a result only one CPU runs patch_text_stop_machine potentially leaving stale icache entries on other CPUs. Fix that by calling stop_machine_cpuslocked with cpu_online_mask as the last argument. Cc: stable@vger.kernel.org Fixes: 64711f9a47d4 ("xtensa: implement jump_label support") Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08DEC: Limit PMAX memory probing to R3k systemsMaciej W. Rozycki2-11/+6
commit 244eae91a94c6dab82b3232967d10eeb9dfa21c6 upstream. Recent tightening of the opcode table in binutils so as to consistently disallow the assembly or disassembly of CP0 instructions not supported by the processor architecture chosen has caused a regression like below: arch/mips/dec/prom/locore.S: Assembler messages: arch/mips/dec/prom/locore.S:29: Error: opcode not supported on this processor: r4600 (mips3) `rfe' in a piece of code used to probe for memory with PMAX DECstation models, which have non-REX firmware. Those computers always have an R2000 CPU and consequently the exception handler used in memory probing uses the RFE instruction, which those processors use. While adding 64-bit support this code was correctly excluded for 64-bit configurations, however it should have also been excluded for irrelevant 32-bit configurations. Do this now then, and only enable PMAX memory probing for R3k systems. Reported-by: Jan-Benedict Glaw <jbglaw@lug-owl.de> Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org # v2.6.12+ Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08ARM: dts: exynos: add missing HDMI supplies on SMDK5420Krzysztof Kozlowski1-0/+3
commit 453a24ded415f7fce0499c6b0a2c7b28f84911f2 upstream. Add required VDD supplies to HDMI block on SMDK5420. Without them, the HDMI driver won't probe. Because of lack of schematics, use same supplies as on Arndale Octa and Odroid XU3 boards (voltage matches). Cc: <stable@vger.kernel.org> # v3.15+ Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20220208171823.226211-3-krzysztof.kozlowski@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08ARM: dts: exynos: add missing HDMI supplies on SMDK5250Krzysztof Kozlowski1-0/+3
commit 60a9914cb2061ba612a3f14f6ad329912b486360 upstream. Add required VDD supplies to HDMI block on SMDK5250. Without them, the HDMI driver won't probe. Because of lack of schematics, use same supplies as on Arndale 5250 board (voltage matches). Cc: <stable@vger.kernel.org> # v3.15+ Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20220208171823.226211-2-krzysztof.kozlowski@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08ARM: dts: exynos: fix UART3 pins configuration in Exynos5250Krzysztof Kozlowski1-1/+1
commit 372d7027fed43c8570018e124cf78b89523a1f8e upstream. The gpa1-4 pin was put twice in UART3 pin configuration of Exynos5250, instead of proper pin gpa1-5. Fixes: f8bfe2b050f3 ("ARM: dts: add pin state information in client nodes for Exynos5 platforms") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20211230195325.328220-1-krzysztof.kozlowski@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08ARM: dts: at91: sama5d2: Fix PMERRLOC resource sizeTudor Ambarus1-1/+1
commit 0fb578a529ac7aca326a9fa475b4a6f58a756fda upstream. PMERRLOC resource size was set to 0x100, which resulted in HSMC_ERRLOCx register being truncated to offset x = 21, causing error correction to fail if more than 22 bit errors and if 24 or 32 bit error correction was supported. Fixes: d9c41bf30cf8 ("ARM: dts: at91: Declare EBI/NAND controllers") Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Cc: <stable@vger.kernel.org> # 4.13.x Acked-by: Alexander Dahl <ada@thorsis.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220111132301.906712-1-tudor.ambarus@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08arm64: dts: ti: k3-j7200: Fix gic-v3 compatible regsNishanth Menon2-1/+5
commit 1a307cc299430dd7139d351a3b8941f493dfa885 upstream. Though GIC ARE option is disabled for no GIC-v2 compatibility, Cortex-A72 is free to implement the CPU interface as long as it communicates with the GIC using the stream protocol. This requires that the SoC integration mark out the PERIPHBASE[1] as reserved area within the SoC. See longer discussion in [2] for further information. Update the GIC register map to indicate offsets from PERIPHBASE based on [3]. Without doing this, systems like kvm will not function with gic-v2 emulation. [1] https://developer.arm.com/documentation/100095/0002/system-control/aarch64-register-descriptions/configuration-base-address-register--el1 [2] https://lore.kernel.org/all/87k0e0tirw.wl-maz@kernel.org/ [3] https://developer.arm.com/documentation/100095/0002/way1382452674438 Cc: stable@vger.kernel.org Fixes: d361ed88455f ("arm64: dts: ti: Add support for J7200 SoC") Reported-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220215201008.15235-4-nm@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08arm64: dts: ti: k3-j721e: Fix gic-v3 compatible regsNishanth Menon2-1/+5
commit a06ed27f3bc63ab9e10007dc0118d910908eb045 upstream. Though GIC ARE option is disabled for no GIC-v2 compatibility, Cortex-A72 is free to implement the CPU interface as long as it communicates with the GIC using the stream protocol. This requires that the SoC integration mark out the PERIPHBASE[1] as reserved area within the SoC. See longer discussion in [2] for further information. Update the GIC register map to indicate offsets from PERIPHBASE based on [3]. Without doing this, systems like kvm will not function with gic-v2 emulation. [1] https://developer.arm.com/documentation/100095/0002/system-control/aarch64-register-descriptions/configuration-base-address-register--el1 [2] https://lore.kernel.org/all/87k0e0tirw.wl-maz@kernel.org/ [3] https://developer.arm.com/documentation/100095/0002/way1382452674438 Cc: stable@vger.kernel.org # 5.10+ Fixes: 2d87061e70de ("arm64: dts: ti: Add Support for J721E SoC") Reported-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220215201008.15235-3-nm@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08arm64: dts: ti: k3-am65: Fix gic-v3 compatible regsNishanth Menon2-1/+5
commit 8cae268b70f387ff9e697ccd62fb2384079124e7 upstream. Though GIC ARE option is disabled for no GIC-v2 compatibility, Cortex-A53 is free to implement the CPU interface as long as it communicates with the GIC using the stream protocol. This requires that the SoC integration mark out the PERIPHBASE[1] as reserved area within the SoC. See longer discussion in [2] for further information. Update the GIC register map to indicate offsets from PERIPHBASE based on [3]. Without doing this, systems like kvm will not function with gic-v2 emulation. [1] https://developer.arm.com/documentation/ddi0500/e/system-control/aarch64-register-descriptions/configuration-base-address-register--el1 [2] https://lore.kernel.org/all/87k0e0tirw.wl-maz@kernel.org/ [3] https://developer.arm.com/documentation/ddi0500/e/generic-interrupt-controller-cpu-interface/gic-programmers-model/memory-map Cc: stable@vger.kernel.org # 5.10+ Fixes: ea47eed33a3f ("arm64: dts: ti: Add Support for AM654 SoC") Reported-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220215201008.15235-2-nm@ti.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08arm64: signal: nofpsimd: Do not allocate fp/simd context when not availableDavid Engraf1-4/+6
commit 0a32c88ddb9af30e8a16d41d7b9b824c27d29459 upstream. Commit 6d502b6ba1b2 ("arm64: signal: nofpsimd: Handle fp/simd context for signal frames") introduced saving the fp/simd context for signal handling only when support is available. But setup_sigframe_layout() always reserves memory for fp/simd context. The additional memory is not touched because preserve_fpsimd_context() is not called and thus the magic is invalid. This may lead to an error when parse_user_sigframe() checks the fp/simd area and does not find a valid magic number. Signed-off-by: David Engraf <david.engraf@sysgo.com> Reviwed-by: Mark Brown <broonie@kernel.org> Fixes: 6d502b6ba1b267b3 ("arm64: signal: nofpsimd: Handle fp/simd context for signal frames") Cc: <stable@vger.kernel.org> # 5.6.x Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220225104008.820289-1-david.engraf@sysgo.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08powerpc/kvm: Fix kvm_use_magic_pageAndreas Gruenbacher1-1/+1
commit 0c8eb2884a42d992c7726539328b7d3568f22143 upstream. When switching from __get_user to fault_in_pages_readable, commit 9f9eae5ce717 broke kvm_use_magic_page: like __get_user, fault_in_pages_readable returns 0 on success. Fixes: 9f9eae5ce717 ("powerpc/kvm: Prefer fault_in_pages_readable function") Cc: stable@vger.kernel.org # v4.18+ Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08riscv: Increase stack size under KASANDmitry Vyukov1-2/+8
commit b81d591386c3a50b96dddcf663628ea0df0bf2b3 upstream. KASAN requires more stack space because of compiler instrumentation. Increase stack size as other arches do. Signed-off-by: Dmitry Vyukov <dvyukov@google.com> Reported-by: syzbot+0600986d88e2d4d7ebb8@syzkaller.appspotmail.com Fixes: 8ad8b72721d0 ("riscv: Add KASAN support") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08riscv: Fix fill_callchain return valueNikita Shubin1-1/+1
commit 2b2b574ac587ec5bd7716a356492a85ab8b0ce9f upstream. perf_callchain_store return 0 on success, -1 otherwise, fix fill_callchain to return correct bool value. Fixes: dbeb90b0c1eb ("riscv: Add perf callchain support") Signed-off-by: Nikita Shubin <n.shubin@yadro.com> Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08ARM: mstar: Select HAVE_ARM_ARCH_TIMERDaniel Palmer1-0/+1
[ Upstream commit ea49432d184a6a09f84461604b7711a4e9f5ec9c ] The mstar SoCs have an arch timer but HAVE_ARM_ARCH_TIMER wasn't selected. If MSC313E_TIMER isn't selected then the kernel gets stuck at boot because there are no timers available. Signed-off-by: Daniel Palmer <daniel@0x0f.com> Link: https://lore.kernel.org/r/20220301104349.3040422-1-daniel@0x0f.com' Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-28nds32: fix access_ok() checks in get/put_userArnd Bergmann1-5/+17
commit 8926d88ced46700bf6117ceaf391480b943ea9f4 upstream. The get_user()/put_user() functions are meant to check for access_ok(), while the __get_user()/__put_user() functions don't. This broke in 4.19 for nds32, when it gained an extraneous check in __get_user(), but lost the check it needs in __put_user(). Fixes: 487913ab18c2 ("nds32: Extract the checking and getting pointer to a macro") Cc: stable@vger.kernel.org @ v4.19+ Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-28ACPI / x86: Work around broken XSDT on Advantech DAC-BJ01 boardMark Cilissen1-0/+24
commit e702196bf85778f2c5527ca47f33ef2e2fca8297 upstream. On this board the ACPI RSDP structure points to both a RSDT and an XSDT, but the XSDT points to a truncated FADT. This causes all sorts of trouble and usually a complete failure to boot after the following error occurs: ACPI Error: Unsupported address space: 0x20 (*/hwregs-*) ACPI Error: AE_SUPPORT, Unable to initialize fixed events (*/evevent-*) ACPI: Unable to start ACPI Interpreter This leaves the ACPI implementation in such a broken state that subsequent kernel subsystem initialisations go wrong, resulting in among others mismapped PCI memory, SATA and USB enumeration failures, and freezes. As this is an older embedded platform that will likely never see any BIOS updates to address this issue and its default shipping OS only complies to ACPI 1.0, work around this by forcing `acpi=rsdt`. This patch, applied on top of Linux 5.10.102, was confirmed on real hardware to fix the issue. Signed-off-by: Mark Cilissen <mark@yotsuba.nl> Cc: All applicable <stable@vger.kernel.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-23arm64: fix clang warning about TRAMP_VALIASArnd Bergmann1-2/+2
[ Upstream commit 7f34b43e07cb512b28543fdcb9f35d1fbfda9ebc ] The newly introduced TRAMP_VALIAS definition causes a build warning with clang-14: arch/arm64/include/asm/vectors.h:66:31: error: arithmetic on a null pointer treated as a cast from integer to pointer is a GNU extension [-Werror,-Wnull-pointer-arithmetic] return (char *)TRAMP_VALIAS + SZ_2K * slot; Change the addition to something clang does not complain about. Fixes: bd09128d16fa ("arm64: Add percpu vectors for EL1") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20220316183833.1563139-1-arnd@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-19arm64: kvm: Fix copy-and-paste error in bhb templates for v5.10 stableJames Morse1-2/+2
KVM's infrastructure for spectre mitigations in the vectors in v5.10 and earlier is different, it uses templates which are used to build a set of vectors at runtime. There are two copy-and-paste errors in the templates: __spectre_bhb_loop_k24 should loop 24 times and __spectre_bhb_loop_k32 32. Fix these. Reported-by: Pavel Machek <pavel@denx.de> Link: https://lore.kernel.org/all/20220310234858.GB16308@amd/ Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-03-19MIPS: smp: fill in sibling and core maps earlierAlexander Lobakin1-3/+3
[ Upstream commit f2703def339c793674010cc9f01bfe4980231808 ] After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle), 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting the following: [ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi)) [ 0.048183] ------------[ cut here ]------------ [ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [ 0.048220] Modules linked in: [ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f [ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 [ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000 [ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34 [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933 [ 0.048389] ... [ 0.048396] Call Trace: [ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140 [ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80 [ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4 [ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c [ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240 [ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80 [ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140 [ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140 [ 0.048523] [<8106593c>] start_secondary+0xbc/0x280 [ 0.048539] [ 0.048543] ---[ end trace 0000000000000000 ]--- [ 0.048636] Synchronize counters for CPU 1: done. ...for each but CPU 0/boot. Basic debug printks right before the mentioned line say: [ 0.048170] CPU: 1, smt_mask: So smt_mask, which is sibling mask obviously, is empty when entering the function. This is critical, as sched_core_cpu_starting() calculates core-scheduling parameters only once per CPU start, and it's crucial to have all the parameters filled in at that moment (at least it uses cpu_smt_mask() which in fact is `&cpu