summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2021-01-15arm64: dts: qcom: sm8250: Define CPU topologyDanny Lin
sm8250 has a big.LITTLE CPU setup with DynamIQ, so all cores are within the same CPU cluster and LLC (Last-Level Cache) domain. Define this topology to help the scheduler make decisions. Signed-off-by: Danny Lin <danny@kdrag0n.dev> Link: https://lore.kernel.org/r/20210112013255.415253-1-danny@kdrag0n.dev Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15MIPS: bitops: fix -Wshadow in asm/bitops.hAlexander Lobakin
Solves the following repetitive warning when building with -Wshadow: In file included from ./include/linux/bitops.h:32, from ./include/linux/kernel.h:11, from ./include/linux/skbuff.h:13, from ./include/linux/if_ether.h:19, from ./include/linux/etherdevice.h:20: ./arch/mips/include/asm/bitops.h: In function ‘test_and_set_bit_lock’: ./arch/mips/include/asm/bitops.h:46:16: warning: declaration of ‘orig’ shadows a previous local [-Wshadow] 46 | unsigned long orig, temp; \ | ^~~~ ./arch/mips/include/asm/bitops.h:190:10: note: in expansion of macro ‘__test_bit_op’ 190 | orig = __test_bit_op(*m, "%0", | ^~~~~~~~~~~~~ ./arch/mips/include/asm/bitops.h:185:21: note: shadowed declaration is here 185 | unsigned long res, orig; | ^~~~ ./arch/mips/include/asm/bitops.h: In function ‘test_and_clear_bit’: ./arch/mips/include/asm/bitops.h:46:16: warning: declaration of ‘orig’ shadows a previous local [-Wshadow] 46 | unsigned long orig, temp; \ | ^~~~ ./arch/mips/include/asm/bitops.h:236:9: note: in expansion of macro ‘__test_bit_op’ 236 | res = __test_bit_op(*m, "%1", | ^~~~~~~~~~~~~ ./arch/mips/include/asm/bitops.h:229:21: note: shadowed declaration is here 229 | unsigned long res, orig; | ^~~~ ./arch/mips/include/asm/bitops.h:46:16: warning: declaration of ‘orig’ shadows a previous local [-Wshadow] 46 | unsigned long orig, temp; \ | ^~~~ ./arch/mips/include/asm/bitops.h:241:10: note: in expansion of macro ‘__test_bit_op’ 241 | orig = __test_bit_op(*m, "%0", | ^~~~~~~~~~~~~ ./arch/mips/include/asm/bitops.h:229:21: note: shadowed declaration is here 229 | unsigned long res, orig; | ^~~~ ./arch/mips/include/asm/bitops.h: In function ‘test_and_change_bit’: ./arch/mips/include/asm/bitops.h:46:16: warning: declaration of ‘orig’ shadows a previous local [-Wshadow] 46 | unsigned long orig, temp; \ | ^~~~ ./arch/mips/include/asm/bitops.h:273:10: note: in expansion of macro ‘__test_bit_op’ 273 | orig = __test_bit_op(*m, "%0", | ^~~~~~~~~~~~~ ./arch/mips/include/asm/bitops.h:266:21: note: shadowed declaration is here 266 | unsigned long res, orig; | ^~~~ Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-01-15MIPS: select ARCH_WANT_LD_ORPHAN_WARNAlexander Lobakin
Now, after that all the sections are explicitly described and declared in vmlinux.lds.S, we can enable ld orphan warnings to prevent from missing any new sections in future. Signed-off-by: Alexander Lobakin <alobakin@pm.me> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-01-15MIPS: vmlinux.lds.S: explicitly declare .got tableAlexander Lobakin
LLVM stack generates GOT table when building the kernel: ld.lld: warning: <internal>:(.got) is being placed in '.got' According to the debug assertions, it's not zero-sized and thus can't be handled the way it's done for x86. Also use the ARM64 path here and place it at the end of .text section. Reported-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alexander Lobakin <alobakin@pm.me> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-01-15MIPS: vmlinux.lds.S: explicitly catch .rel.dyn symbolsAlexander Lobakin
According to linker warnings, both GCC and LLVM generate '.rel.dyn' symbols: mips-alpine-linux-musl-ld: warning: orphan section `.rel.dyn' from `init/main.o' being placed in section `.rel.dyn' Link-time assertion shows that this section is sometimes empty, sometimes not, depending on machine bitness and the compiler [0]: LD .tmp_vmlinux.kallsyms1 mips64-linux-gnu-ld: Unexpected run-time relocations (.rel) detected! Just use the ARM64 approach and declare it in vmlinux.lds.S closer to __init_end. [0] https://lore.kernel.org/linux-mips/20210109111259.GA4213@alpha.franken.de Reported-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Alexander Lobakin <alobakin@pm.me> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-01-15MIPS: properly stop .eh_frame generationAlexander Lobakin
Commit 866b6a89c6d1 ("MIPS: Add DWARF unwinding to assembly") added -fno-asynchronous-unwind-tables to KBUILD_CFLAGS to prevent compiler from emitting .eh_frame symbols. However, as MIPS heavily uses CFI, that's not enough. Use the approach taken for x86 (as it also uses CFI) and explicitly put CFI symbols into the .debug_frame section (except for VDSO). This allows us to drop .eh_frame from DISCARDS as it's no longer being generated. Fixes: 866b6a89c6d1 ("MIPS: Add DWARF unwinding to assembly") Suggested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Alexander Lobakin <alobakin@pm.me> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-01-15MIPS: vmlinux.lds.S: add ".gnu.attributes" to DISCARDSAlexander Lobakin
Discard GNU attributes (MIPS FP type, GNU Hash etc.) at link time as kernel doesn't use it at all. Solves a dozen of the following ld warnings (one per every file): mips-alpine-linux-musl-ld: warning: orphan section `.gnu.attributes' from `arch/mips/kernel/head.o' being placed in section `.gnu.attributes' mips-alpine-linux-musl-ld: warning: orphan section `.gnu.attributes' from `init/main.o' being placed in section `.gnu.attributes' Signed-off-by: Alexander Lobakin <alobakin@pm.me> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-01-15MIPS: CPS: don't create redundant .text.cps-vec sectionAlexander Lobakin
A number of symbols from arch/mips/kernel/cps-vec.S is explicitly placed into '.text.cps-vec' section. There are no direct references to this section, so there's no need to form it. '.balign 0x1000' directive will work anyway. Moreover, this section was being placed in vmlinux differently depending on CONFIG_LD_DEAD_CODE_DATA_ELIMINATION: - with this option enabled, '.text.cps-vec' was being caught by '.text.[0-9a-zA-Z_]*' from include/asm-generic/vmlinux.lds.h; - without this option, '.text.cps-vec' was being caught by discouraging '.text.*' from arch/mips/kernel/vmlinux.lds.S. '.text.*' should not be used in vmlinux linker scripts at all as it silently catches any orphan text sections. So, remove both '.section .text.cps-vec' and '.text.*' from cps-vec.S and vmlinux.lds.S respectively. As said, this does not affect related functions alignment: 80116000 T mips_cps_core_entry 80116028 t not_nmi 80116200 T excep_tlbfill 80116280 T excep_xtlbfill 80116300 T excep_cache 80116380 T excep_genex 80116400 T excep_intex 80116480 T excep_ejtag 80116490 T mips_cps_core_init Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-01-15MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() sectionAlexander Lobakin
MIPS uses its own declaration of rwdata, and thus it should be kept in sync with the asm-generic one. Currently PAGE_ALIGNED_DATA() is missing from the linker script, which emits the following ld warnings: mips-alpine-linux-musl-ld: warning: orphan section `.data..page_aligned' from `arch/mips/kernel/vdso.o' being placed in section `.data..page_aligned' mips-alpine-linux-musl-ld: warning: orphan section `.data..page_aligned' from `arch/mips/vdso/vdso-image.o' being placed in section `.data..page_aligned' Add the necessary declaration, so the mentioned structures will be placed in vmlinux as intended: ffffffff80630580 D __end_once ffffffff80630580 D __start___dyndbg ffffffff80630580 D __start_once ffffffff80630580 D __stop___dyndbg ffffffff80634000 d mips_vdso_data ffffffff80638000 d vdso_data ffffffff80638580 D _gp ffffffff8063c000 T __init_begin ffffffff8063c000 D _edata ffffffff8063c000 T _sinittext -> ffffffff805a4000 D __end_init_task ffffffff805a4000 D __nosave_begin ffffffff805a4000 D __nosave_end ffffffff805a4000 d mips_vdso_data ffffffff805a8000 d vdso_data ffffffff805ac000 D mmlist_lock ffffffff805ac080 D tasklist_lock Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Signed-off-by: Alexander Lobakin <alobakin@pm.me> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Cc: stable@vger.kernel.org # 4.4+ Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-01-15arm64: dts: qcom: msm8916-samsung-a2015: Fix sensorsStephan Gerhold
When the BMC150 accelerometer/magnetometer was added to the device tree, the sensors were working without specifying any regulator supplies, likely because the regulators were on by default and then never turned off. For some reason, this is no longer the case for pm8916_l17, which prevents the sensors from working in some cases. Now that the bmc150_accel/bmc150_magn drivers can enable necessary regulators, declare the necessary regulator supplies to make the sensors work again. Fixes: 079f81acf10f ("arm64: dts: qcom: msm8916-samsung-a2015: Add accelerometer/magnetometer") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20210111175358.97171-1-stephan@gerhold.net Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: dts: sdm850: Add OPP tables for 2.84 and 2.96GHzSteev Klimaszewski
Running cpufreq-hw driver on Lenovo Yoga C630 laptop, the following warning messages will be seen. [ 3.415340] cpu cpu4: Voltage update failed freq=2841600 [ 3.418755] cpu cpu4: failed to update OPP for freq=2841600 [ 3.422949] cpu cpu4: Voltage update failed freq=2956800 [ 3.427086] cpu cpu4: failed to update OPP for freq=2956800 This is because the cpufreq-hw lookup table of SDM850 provides these two set-points, but they are missing from OPP table in DT. Let's create sdm850.dtsi to add the OPP for them, so that the warning will be gone. Signed-off-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Link: https://lore.kernel.org/r/20210112090640.20062-1-shawn.guo@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15arm64: dts: sdm845: add oneplus6/6t devicesCaleb Connolly
Add initial support for the OnePlus 6 (enchilada) and 6T (fajita) based on the sdm845-mtp DT with the following functionality: * Touch * Display * GPU * Wlan and Bluetooth * USB peripheral mode * Remoteproc Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Caleb Connolly <caleb@connolly.tech> Link: https://lore.kernel.org/r/20210114203057.64541-2-caleb@connolly.tech Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-15drivers: bus: simple-pm-bus: Fix compatibility with simple-bus for auxdataTony Lindgren
After converting am335x to probe devices with simple-pm-bus I noticed that we are not passing auxdata for of_platform_populate() like we do with simple-bus. While device tree using SoCs should no longer need platform data, there are still quite a few drivers that still need it as can be seen with git grep OF_DEV_AUXDATA. We want to have simple-pm-bus be usable as a replacement for simple-bus also for cases where OF_DEV_AUXDATA is still needed. Let's fix the issue by passing auxdata as platform data to simple-pm-bus. That way the SoCs needing this can pass the auxdata with OF_DEV_AUXDATA. And let's pass the auxdata for omaps to fix the issue for am335x. As an alternative solution, adding simple-pm-bus handling directly to drivers/of/platform.c was considered, but we would still need simple-pm-bus device driver. So passing auxdata as platform data seems like the simplest solution. Fixes: 5a230524f879 ("ARM: dts: Use simple-pm-bus for genpd for am3 l4_wkup") Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-01-15ARM: OMAP2+: Fix booting for am335x after moving to simple-pm-busTony Lindgren
We now depend on SIMPLE_PM_BUS for probing devices. While we have it selected in omap2plus_defconfig, custom configs can fail if it's missing. As SIMPLE_PM_BUS depends on OF and PM, we must now select PM in Kconfig. We have already OF selected by ARCH_MULTIPLATFORM. Let's also drop the earlier PM dependency entries as suggested by Geert Uytterhoeven <geert@linux-m68k.org>. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Reported-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Fixes: 5a230524f879 ("ARM: dts: Use simple-pm-bus for genpd for am3 l4_wkup") Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-01-15Merge branch 'cpuidle-fix' into fixesTony Lindgren
2021-01-15ARM: OMAP2+: Fix suspcious RCU usage splats for omap_enter_idle_coupledTony Lindgren
We get suspcious RCU usage splats with cpuidle in several places in omap_enter_idle_coupled() with the kernel debug options enabled: RCU used illegally from extended quiescent state! ... (_raw_spin_lock_irqsave) (omap_enter_idle_coupled+0x17c/0x2d8) (omap_enter_idle_coupled) (cpuidle_enter_state) (cpuidle_enter_state_coupled) (cpuidle_enter) Let's use RCU_NONIDLE to suppress these splats. Things got changed around with commit 1098582a0f6c ("sched,idle,rcu: Push rcu_idle deeper into the idle path") that started triggering these warnings. For the tick_broadcast related calls, ideally we'd just switch over to using CPUIDLE_FLAG_TIMER_STOP for omap_enter_idle_coupled() to have the generic cpuidle code handle the tick_broadcast related calls for us and then just drop the tick_broadcast calls here. But we're currently missing the call in the common cpuidle code for tick_broadcast_enable() that CPU1 hotplug needs as described in earlier commit 50d6b3cf9403 ("ARM: OMAP2+: fix lack of timer interrupts on CPU1 after hotplug"). Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Paul E. McKenney <paulmck@kernel.org> Cc: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-01-15arm64: defconfig: Enable interconnect for imx8mqMartin Kepplinger
Enable INTERCONNECT_IMX8MQ in order to make interconnect more widely available. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Acked-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-15arm64: dts: imx8mq: Add interconnect for lcdifMartin Kepplinger
Add interconnect ports for lcdif to set bus capabilities. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-15arm64: dts: imx8mq: Add interconnect provider propertyMartin Kepplinger
Add #interconnect-cells on main &noc so that it will probe the interconnect provider. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Acked-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-15arm64: dts: imx8mq: Add NOC nodeLeonard Crestez
Add initial support for dynamic frequency scaling of the main NOC on imx8mq. Make DDRC the parent of the NOC (using passive governor) so that the main NOC is automatically scaled together with DDRC by default. Support for proactive scaling via interconnect will come on top. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Acked-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-15arm64: syscall: include prototype for EL0 SVC functionsMark Rutland
The kbuild test robot reports that when building with W=1, GCC will warn for a couple of missing prototypes in syscall.c: | arch/arm64/kernel/syscall.c:157:6: warning: no previous prototype for 'do_el0_svc' [-Wmissing-prototypes] | 157 | void do_el0_svc(struct pt_regs *regs) | | ^~~~~~~~~~ | arch/arm64/kernel/syscall.c:164:6: warning: no previous prototype for 'do_el0_svc_compat' [-Wmissing-prototypes] | 164 | void do_el0_svc_compat(struct pt_regs *regs) | | ^~~~~~~~~~~~~~~~~ While this isn't a functional problem, as a general policy we should include the prototype for functions wherever possible to catch any accidental divergence between the prototype and implementation. Here we can easily include <asm/exception.h>, so let's do so. While there are a number of warnings elsewhere and some warnings enabled under W=1 are of questionable benefit, this change helps to make the code more robust as it evolved and reduces the noise somewhat, so it seems worthwhile. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reported-by: kernel test robot <lkp@intel.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/202101141046.n8iPO3mw-lkp@intel.com Link: https://lore.kernel.org/r/20210114124812.17754-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-01-15arm64: dts: freescale: sl28: add variant 1Michael Walle
There is a new variant 1 of this board available. It features up to four SerDes lanes for customer use. Add a new device tree which features just the basic peripherals. A customer will then have to modify or append to this device tree. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-01-15x86: Remove definition of DEBUGTom Rix
Defining DEBUG should only be done in development. So remove it. Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lkml.kernel.org/r/20210114212827.47584-1-trix@redhat.com
2021-01-14arm64: dts: qcom: sm8250: correct sdhc_2 xo clkDmitry Baryshkov
sdhc_2 uses 19200000 Hz clock rather than wrongly specified xo_board (39400000 Hz). Specify correct clock to fix DLL setup for SDR104 mode. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: c4cf0300be84 ("arm64: dts: qcom: sm8250: Add support for SDC2") Link: https://lore.kernel.org/r/20210109011252.3436533-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-14arm64: dts: qcom: qrb5165-rb5: add HDMI audio playbackDmitry Baryshkov
Add support for audio output over the HDMI output using Tertiary I2S and LT9611UXC DSI-to-HDMI bridge. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210115024713.92574-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-14arm64: dts: qcom: qrb5165-rb5: enable cdsp deviceDmitry Baryshkov
Enable Compute DSP (cdsp) on QRB5165-RB5 platform and provide firmware filename used to boot the cdsp. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210115024156.92265-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-14bpf: Add bitwise atomic instructionsBrendan Jackman
This adds instructions for atomic[64]_[fetch_]and atomic[64]_[fetch_]or atomic[64]_[fetch_]xor All these operations are isomorphic enough to implement with the same verifier, interpreter, and x86 JIT code, hence being a single commit. The main interesting thing here is that x86 doesn't directly support the fetch_ version these operations, so we need to generate a CMPXCHG loop in the JIT. This requires the use of two temporary registers, IIUC it's safe to use BPF_REG_AX and x86's AUX_REG for this purpose. Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20210114181751.768687-10-jackmanb@google.com
2021-01-14bpf: Add instructions for atomic_[cmp]xchgBrendan Jackman
This adds two atomic opcodes, both of which include the BPF_FETCH flag. XCHG without the BPF_FETCH flag would naturally encode atomic_set. This is not supported because it would be of limited value to userspace (it doesn't imply any barriers). CMPXCHG without BPF_FETCH woulud be an atomic compare-and-write. We don't have such an operation in the kernel so it isn't provided to BPF either. There are two significant design decisions made for the CMPXCHG instruction: - To solve the issue that this operation fundamentally has 3 operands, but we only have two register fields. Therefore the operand we compare against (the kernel's API calls it 'old') is hard-coded to be R0. x86 has similar design (and A64 doesn't have this problem). A potential alternative might be to encode the other operand's register number in the immediate field. - The kernel's atomic_cmpxchg returns the old value, while the C11 userspace APIs return a boolean indicating the comparison result. Which should BPF do? A64 returns the old value. x86 returns the old value in the hard-coded register (and also sets a flag). That means return-old-value is easier to JIT, so that's what we use. Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20210114181751.768687-8-jackmanb@google.com
2021-01-14bpf: Add BPF_FETCH field / create atomic_fetch_add instructionBrendan Jackman
The BPF_FETCH field can be set in bpf_insn.imm, for BPF_ATOMIC instructions, in order to have the previous value of the atomically-modified memory location loaded into the src register after an atomic op is carried out. Suggested-by: Yonghong Song <yhs@fb.com> Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20210114181751.768687-7-jackmanb@google.com
2021-01-14bpf: Rename BPF_XADD and prepare to encode other atomics in .immBrendan Jackman
A subsequent patch will add additional atomic operations. These new operations will use the same opcode field as the existing XADD, with the immediate discriminating different operations. In preparation, rename the instruction mode BPF_ATOMIC and start calling the zero immediate BPF_ADD. This is possible (doesn't break existing valid BPF progs) because the immediate field is currently reserved MBZ and BPF_ADD is zero. All uses are removed from the tree but the BPF_XADD definition is kept around to avoid breaking builds for people including kernel headers. Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Björn Töpel <bjorn.topel@gmail.com> Link: https://lore.kernel.org/bpf/20210114181751.768687-5-jackmanb@google.com
2021-01-14bpf: x86: Factor out a lookup table for some ALU opcodesBrendan Jackman
A later commit will need to lookup a subset of these opcodes. To avoid duplicating code, pull out a table. The shift opcodes won't be needed by that later commit, but they're already duplicated, so fold them into the table anyway. Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20210114181751.768687-4-jackmanb@google.com
2021-01-14bpf: x86: Factor out emission of REX byteBrendan Jackman
The JIT case for encoding atomic ops is about to get more complicated. In order to make the review & resulting code easier, let's factor out some shared helpers. Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20210114181751.768687-3-jackmanb@google.com
2021-01-14bpf: x86: Factor out emission of ModR/M for *(reg + off)Brendan Jackman
The case for JITing atomics is about to get more complicated. Let's factor out some common code to make the review and result more readable. NB the atomics code doesn't yet use the new helper - a subsequent patch will add its use as a side-effect of other changes. Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20210114181751.768687-2-jackmanb@google.com
2021-01-14riscv: stacktrace: Move register keyword to beginning of declarationKefeng Wang
Using global sp_in_global directly to fix the following warning, arch/riscv/kernel/stacktrace.c:31:3: warning: ‘register’ is not at beginning of declaration [-Wold-style-declaration] 31 | const register unsigned long current_sp = sp_in_global; | ^~~~~ Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv/stacktrace: Fix stack output without ra on the stack topChen Huang
When a function doesn't have a callee, then it will not push ra into the stack, such as lkdtm_BUG() function, addi sp,sp,-16 sd s0,8(sp) addi s0,sp,16 ebreak The struct stackframe use {fp,ra} to get information from stack, if walk_stackframe() with pr_regs, we will obtain wrong value and bad stacktrace, [<ffffffe00066c56c>] lkdtm_BUG+0x6/0x8 ---[ end trace 18da3fbdf08e25d5 ]--- Correct the next fp and pc, after that, full stacktrace shown as expects, [<ffffffe00066c56c>] lkdtm_BUG+0x6/0x8 [<ffffffe0008b24a4>] lkdtm_do_action+0x14/0x1c [<ffffffe00066c372>] direct_entry+0xc0/0x10a [<ffffffe000439f86>] full_proxy_write+0x42/0x6a [<ffffffe000309626>] vfs_write+0x7e/0x214 [<ffffffe00030992a>] ksys_write+0x98/0xc0 [<ffffffe000309960>] sys_write+0xe/0x16 [<ffffffe0002014bc>] ret_from_syscall+0x0/0x2 ---[ end trace 61917f3d9a9fadcd ]--- Signed-off-by: Chen Huang <chenhuang5@huawei.com> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Improve __show_regsKefeng Wang
Show the function symbols of epc and ra to improve the readability of crash reports, and align the printing formats about the raw epc value. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Add dump stack in show_regsKefeng Wang
Like commit 1149aad10b1e ("arm64: Add dump_backtrace() in show_regs"), dump the stack in riscv show_regs as common code expects. Reviewed-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Enable per-task stack canariesGuo Ren
This enables the use of per-task stack canary values if GCC has support for emitting the stack canary reference relative to the value of tp, which holds the task struct pointer in the riscv kernel. After compare arm64 and x86 implementations, seems arm64's is more flexible and readable. The key point is how gcc get the offset of stack_canary from gs/el0_sp. x86: Use a fix offset from gs, not flexible. struct fixed_percpu_data { /* * GCC hardcodes the stack canary as %gs:40. Since the * irq_stack is the object at %gs:0, we reserve the bottom * 48 bytes of the irq stack for the canary. */ char gs_base[40]; // :( unsigned long stack_canary; }; arm64: Use -mstack-protector-guard-offset & guard-reg gcc options: -mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=xxx riscv: Use -mstack-protector-guard-offset & guard-reg gcc options: -mstack-protector-guard=tls -mstack-protector-guard-reg=tp -mstack-protector-guard-offset=xxx GCC's implementation has been merged: commit c931e8d5a96463427040b0d11f9c4352ac22b2b0 Author: Cooper Qu <cooper.qu@linux.alibaba.com> Date: Mon Jul 13 16:15:08 2020 +0800 RISC-V: Add support for TLS stack protector canary access In the end, these codes are inserted by gcc before return: * 0xffffffe00020b396 <+120>: ld a5,1008(tp) # 0x3f0 * 0xffffffe00020b39a <+124>: xor a5,a5,a4 * 0xffffffe00020b39c <+126>: mv a0,s5 * 0xffffffe00020b39e <+128>: bnez a5,0xffffffe00020b61c <_do_fork+766> 0xffffffe00020b3a2 <+132>: ld ra,136(sp) 0xffffffe00020b3a4 <+134>: ld s0,128(sp) 0xffffffe00020b3a6 <+136>: ld s1,120(sp) 0xffffffe00020b3a8 <+138>: ld s2,112(sp) 0xffffffe00020b3aa <+140>: ld s3,104(sp) 0xffffffe00020b3ac <+142>: ld s4,96(sp) 0xffffffe00020b3ae <+144>: ld s5,88(sp) 0xffffffe00020b3b0 <+146>: ld s6,80(sp) 0xffffffe00020b3b2 <+148>: ld s7,72(sp) 0xffffffe00020b3b4 <+150>: addi sp,sp,144 0xffffffe00020b3b6 <+152>: ret ... * 0xffffffe00020b61c <+766>: auipc ra,0x7f8 * 0xffffffe00020b620 <+770>: jalr -1764(ra) # 0xffffffe000a02f38 <__stack_chk_fail> Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Signed-off-by: Cooper Qu <cooper.qu@linux.alibaba.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Add support for function error injectionGuo Ren
Inspired by the commit 42d038c4fb00 ("arm64: Add support for function error injection"), this patch supports function error injection for riscv. This patch mainly support two functions: one is regs_set_return_value() which is used to overwrite the return value; the another function is override_function_with_return() which is to override the probed function returning and jump to its caller. Test log: cd /sys/kernel/debug/fail_function echo sys_clone > inject echo 100 > probability echo 1 > interval ls / [ 313.176875] FAULT_INJECTION: forcing a failure. [ 313.176875] name fail_function, interval 1, probability 100, space 0, times 1 [ 313.184357] CPU: 0 PID: 87 Comm: sh Not tainted 5.8.0-rc5-00007-g6a758cc #117 [ 313.187616] Call Trace: [ 313.189100] [<ffffffe0002036b6>] walk_stackframe+0x0/0xc2 [ 313.191626] [<ffffffe00020395c>] show_stack+0x40/0x4c [ 313.193927] [<ffffffe000556c60>] dump_stack+0x7c/0x96 [ 313.194795] [<ffffffe0005522e8>] should_fail+0x140/0x142 [ 313.195923] [<ffffffe000299ffc>] fei_kprobe_handler+0x2c/0x5a [ 313.197687] [<ffffffe0009e2ec4>] kprobe_breakpoint_handler+0xb4/0x18a [ 313.200054] [<ffffffe00020357e>] do_trap_break+0x36/0xca [ 313.202147] [<ffffffe000201bca>] ret_from_exception+0x0/0xc [ 313.204556] [<ffffffe000201bbc>] ret_from_syscall+0x0/0x2 -sh: can't fork: Invalid argument Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Add uprobes supportedGuo Ren
This patch adds support for uprobes on riscv architecture. Just like kprobe, it support single-step and simulate instructions. Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Reviewed-by: Pekka Enberg <penberg@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Add KPROBES_ON_FTRACE supportedGuo Ren
This patch adds support for kprobes on ftrace call sites to avoids much of the overhead with regular kprobes. Try it with simple steps: echo 'p:myprobe sys_clone a0=%a0 a1=%a1 stack_val=+4($stack)' > /sys/kernel/de bug/tracing/kprobe_events echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable cat /sys/kernel/debug/tracing/trace tracer: nop entries-in-buffer/entries-written: 1/1 #P:1 _-----=> irqs-off / _----=> need-resched | / _---=> hardirq/softirq || / _--=> preempt-depth ||| / delay TASK-PID CPU# |||| TIMESTAMP FUNCTION | | | |||| | | sh-92 [000] .... 369.899962: myprobe: (sys_clone+0x0/0x28) a0=0x1200011 a1=0x0 stack_val=0x201c20ffffffe0 cat /sys/kernel/debug/kprobes/list ffffffe00020b584 k sys_clone+0x0 [FTRACE] ^^^^^^ Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Add kprobes supportedGuo Ren
This patch enables "kprobe & kretprobe" to work with ftrace interface. It utilized software breakpoint as single-step mechanism. Some instructions which can't be single-step executed must be simulated in kernel execution slot, such as: branch, jal, auipc, la ... Some instructions should be rejected for probing and we use a blacklist to filter, such as: ecall, ebreak, ... We use ebreak & c.ebreak to replace origin instruction and the kprobe handler prepares an executable memory slot for out-of-line execution with a copy of the original instruction being probed. In execution slot we add ebreak behind original instruction to simulate a single-setp mechanism. The patch is based on packi's work [1] and csky's work [2]. - The kprobes_trampoline.S is all from packi's patch - The single-step mechanism is new designed for riscv without hw single-step trap - The simulation codes are from csky - Frankly, all codes refer to other archs' implementation [1] https://lore.kernel.org/linux-riscv/20181113195804.22825-1-me@packi.ch/ [2] https://lore.kernel.org/linux-csky/20200403044150.20562-9-guoren@kernel.org/ Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Co-developed-by: Patrick Stählin <me@packi.ch> Signed-off-by: Patrick Stählin <me@packi.ch> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Tested-by: Zong Li <zong.li@sifive.com> Reviewed-by: Pekka Enberg <penberg@kernel.org> Cc: Patrick Stählin <me@packi.ch> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Björn Töpel <bjorn.topel@gmail.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNTGuo Ren
This patch changes the current detour mechanism of dynamic ftrace which has been discussed during LPC 2020 RISCV-MC [1]. Before the patch, we used mcount for detour: <funca>: addi sp,sp,-16 sd ra,8(sp) sd s0,0(sp) addi s0,sp,16 mv a5,ra mv a0,a5 auipc ra,0x0 -> nop jalr -296(ra) <_mcount@plt> ->nop ... After the patch, we use nop call site area for detour: <funca>: nop -> REG_S ra, -SZREG(sp) nop -> auipc ra, 0x? nop -> jalr ?(ra) nop -> REG_L ra, -SZREG(sp) ... The mcount mechanism is mixed with gcc function prologue which is not very clear. The patchable function entry just put 16 bytes nop before the front of the function prologue which could be filled with a separated detour mechanism. [1] https://www.linuxplumbersconf.org/event/7/contributions/807/ Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Fixup patch_text panic in ftraceGuo Ren
Just like arm64, we can't trace the function in the patch_text path. Here is the bug log: [ 45.234334] Unable to handle kernel paging request at virtual address ffffffd38ae80900 [ 45.242313] Oops [#1] [ 45.244600] Modules linked in: [ 45.247678] CPU: 0 PID: 11 Comm: migration/0 Not tainted 5.9.0-00025-g9b7db83-dirty #215 [ 45.255797] epc: ffffffe00021689a ra : ffffffe00021718e sp : ffffffe01afabb58 [ 45.262955] gp : ffffffe00136afa0 tp : ffffffe01af94d00 t0 : 0000000000000002 [ 45.270200] t1 : 0000000000000000 t2 : 0000000000000001 s0 : ffffffe01afabc08 [ 45.277443] s1 : ffffffe0013718a8 a0 : 0000000000000000 a1 : ffffffe01afabba8 [ 45.284686] a2 : 0000000000000000 a3 : 0000000000000000 a4 : c4c16ad38ae80900 [ 45.291929] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000052464e43 [ 45.299173] s2 : 0000000000000001 s3 : ffffffe000206a60 s4 : ffffffe000206a60 [ 45.306415] s5 : 00000000000009ec s6 : ffffffe0013718a8 s7 : c4c16ad38ae80900 [ 45.313658] s8 : 0000000000000004 s9 : 0000000000000001 s10: 0000000000000001 [ 45.320902] s11: 0000000000000003 t3 : 0000000000000001 t4 : ffffffffd192fe79 [ 45.328144] t5 : ffffffffb8f80000 t6 : 0000000000040000 [ 45.333472] status: 0000000200000100 badaddr: ffffffd38ae80900 cause: 000000000000000f [ 45.341514] ---[ end trace d95102172248fdcf ]--- [ 45.346176] note: migration/0[11] exited with preempt_count 1 (gdb) x /2i $pc => 0xffffffe00021689a <__do_proc_dointvec+196>: sd zero,0(s7) 0xffffffe00021689e <__do_proc_dointvec+200>: li s11,0 (gdb) bt 0 __do_proc_dointvec (tbl_data=0x0, table=0xffffffe01afabba8, write=0, buffer=0x0, lenp=0x7bf897061f9a0800, ppos=0x4, conv=0x0, data=0x52464e43) at kernel/sysctl.c:581 1 0xffffffe00021718e in do_proc_dointvec (data=<optimized out>, conv=<optimized out>, ppos=<optimized out>, lenp=<optimized out>, buffer=<optimized out>, write=<optimized out>, table=<optimized out>) at kernel/sysctl.c:964 2 proc_dointvec_minmax (ppos=<optimized out>, lenp=<optimized out>, buffer=<optimized out>, write=<optimized out>, table=<optimized out>) at kernel/sysctl.c:964 3 proc_do_static_key (table=<optimized out>, write=1, buffer=0x0, lenp=0x0, ppos=0x7bf897061f9a0800) at kernel/sysctl.c:1643 4 0xffffffe000206792 in ftrace_make_call (rec=<optimized out>, addr=<optimized out>) at arch/riscv/kernel/ftrace.c:109 5 0xffffffe0002c9c04 in __ftrace_replace_code (rec=0xffffffe01ae40c30, enable=3) at kernel/trace/ftrace.c:2503 6 0xffffffe0002ca0b2 in ftrace_replace_code (mod_flags=<optimized out>) at kernel/trace/ftrace.c:2530 7 0xffffffe0002ca26a in ftrace_modify_all_code (command=5) at kernel/trace/ftrace.c:2677 8 0xffffffe0002ca30e in __ftrace_modify_code (data=<optimized out>) at kernel/trace/ftrace.c:2703 9 0xffffffe0002c13b0 in multi_cpu_stop (data=0x0) at kernel/stop_machine.c:224 10 0xffffffe0002c0fde in cpu_stopper_thread (cpu=<optimized out>) at kernel/stop_machine.c:491 11 0xffffffe0002343de in smpboot_thread_fn (data=0x0) at kernel/smpboot.c:165 12 0xffffffe00022f8b4 in kthread (_create=0xffffffe01af0c040) at kernel/kthread.c:292 13 0xffffffe000201fac in handle_exception () at arch/riscv/kernel/entry.S:236 0xffffffe00020678a <+114>: auipc ra,0xffffe 0xffffffe00020678e <+118>: jalr -118(ra) # 0xffffffe000204714 <patch_text_nosync> 0xffffffe000206792 <+122>: snez a0,a0 (gdb) disassemble patch_text_nosync Dump of assembler code for function patch_text_nosync: 0xffffffe000204714 <+0>: addi sp,sp,-32 0xffffffe000204716 <+2>: sd s0,16(sp) 0xffffffe000204718 <+4>: sd ra,24(sp) 0xffffffe00020471a <+6>: addi s0,sp,32 0xffffffe00020471c <+8>: auipc ra,0x0 0xffffffe000204720 <+12>: jalr -384(ra) # 0xffffffe00020459c <patch_insn_write> 0xffffffe000204724 <+16>: beqz a0,0xffffffe00020472e <patch_text_nosync+26> 0xffffffe000204726 <+18>: ld ra,24(sp) 0xffffffe000204728 <+20>: ld s0,16(sp) 0xffffffe00020472a <+22>: addi sp,sp,32 0xffffffe00020472c <+24>: ret 0xffffffe00020472e <+26>: sd a0,-24(s0) 0xffffffe000204732 <+30>: auipc ra,0x4 0xffffffe000204736 <+34>: jalr -1464(ra) # 0xffffffe00020817a <flush_icache_all> 0xffffffe00020473a <+38>: ld a0,-24(s0) 0xffffffe00020473e <+42>: ld ra,24(sp) 0xffffffe000204740 <+44>: ld s0,16(sp) 0xffffffe000204742 <+46>: addi sp,sp,32 0xffffffe000204744 <+48>: ret (gdb) disassemble flush_icache_all-4 Dump of assembler code for function flush_icache_all: 0xffffffe00020817a <+0>: addi sp,sp,-8 0xffffffe00020817c <+2>: sd ra,0(sp) 0xffffffe00020817e <+4>: auipc ra,0xfffff 0xffffffe000208182 <+8>: jalr -1822(ra) # 0xffffffe000206a60 <ftrace_caller> 0xffffffe000208186 <+12>: ld ra,0(sp) 0xffffffe000208188 <+14>: addi sp,sp,8 0xffffffe00020818a <+0>: addi sp,sp,-16 0xffffffe00020818c <+2>: sd s0,0(sp) 0xffffffe00020818e <+4>: sd ra,8(sp) 0xffffffe000208190 <+6>: addi s0,sp,16 0xffffffe000208192 <+8>: li a0,0 0xffffffe000208194 <+10>: auipc ra,0xfffff 0xffffffe000208198 <+14>: jalr -410(ra) # 0xffffffe000206ffa <sbi_remote_fence_i> 0xffffffe00020819c <+18>: ld s0,0(sp) 0xffffffe00020819e <+20>: ld ra,8(sp) 0xffffffe0002081a0 <+22>: addi sp,sp,16 0xffffffe0002081a2 <+24>: ret (gdb) frame 5 (rec=0xffffffe01ae40c30, enable=3) at kernel/trace/ftrace.c:2503 2503 return ftrace_make_call(rec, ftrace_addr); (gdb) p /x rec->ip $2 = 0xffffffe00020817a -> flush_icache_all ! When we modified flush_icache_all's patchable-entry with ftrace_caller: - Insert ftrace_caller at flush_icache_all prologue. - Call flush_icache_all to sync I/Dcache, but flush_icache_all is just we modified by half. Link: https://lore.kernel.org/linux-riscv/CAJF2gTT=oDWesWe0JVWvTpGi60-gpbNhYLdFWN_5EbyeqoEDdw@mail.gmail.com/T/#t Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Reviewed-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Fixup wrong ftrace remove cflagGuo Ren
We must use $(CC_FLAGS_FTRACE) instead of directly using -pg. It will cause -fpatchable-function-entry error. Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Fixup compile error BUILD_BUG_ON failedGuo Ren
Unfortunately, the current code couldn't be compiled: CC arch/riscv/kernel/patch.o In file included from ./include/linux/kernel.h:11, from ./include/linux/list.h:9, from ./include/linux/preempt.h:11, from ./include/linux/spinlock.h:51, from arch/riscv/kernel/patch.c:6: In function ‘fix_to_virt’, inlined from ‘patch_map’ at arch/riscv/kernel/patch.c:37:17: ./include/linux/compiler.h:392:38: error: call to ‘__compiletime_assert_205’ declared with attribute error: BUILD_BUG_ON failed: idx >= __end_of_fixed_addresses _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ./include/linux/compiler.h:373:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix(); \ ^~~~~~ ./include/linux/compiler.h:392:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~~~~~~~~~~~~~~~~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~~~~~~~~~~~~~~~~~ ./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) ^~~~~~~~~~~~~~~~ ./include/asm-generic/fixmap.h:32:2: note: in expansion of macro ‘BUILD_BUG_ON’ BUILD_BUG_ON(idx >= __end_of_fixed_addresses); ^~~~~~~~~~~~ Because fix_to_virt(, idx) needs a const value, not a dynamic variable of reg-a0 or BUILD_BUG_ON failed with "idx >= __end_of_fixed_addresses". Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org> Reviewed-by: Pekka Enberg <penberg@kernel.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14RISC-V: Implement ptrace regs and stack APIPatrick Stählin
Needed for kprobes support. Copied and adapted from arm64 code. Guo Ren fixup pt_regs type for linux-5.8-rc1. Signed-off-by: Patrick Stählin <me@packi.ch> Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Reviewed-by: Pekka Enberg <penberg@kernel.org> Reviewed-by: Zong Li <zong.li@sifive.com> Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Add machine name to kernel boot log and stack dump outputKefeng Wang
Add the machine name to kernel boot-up log, and install the machine name to stack dump for DT boot mode. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Add numa support for riscv64 platformAtish Patra
Use the generic numa implementation to add NUMA support for RISC-V. This is based on Greentime's patch[1] but modified to use generic NUMA implementation and few more fixes. [1] https://lkml.org/lkml/2020/1/10/233 Co-developed-by: Greentime Hu <greentime.hu@sifive.com> Signed-off-by: Greentime Hu <greentime.hu@sifive.com> Signed-off-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-01-14riscv: Add support pte_protnone and pmd_protnone if CONFIG_NUMA_BALANCINGGreentime Hu
These two functions are used to distinguish between PROT_NONENUMA protections and hinting fault protections. Signed-off-by: Greentime Hu <greentime.hu@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
generated by cgit (git 2.34.1) at 2025-09-24 08:16:56 +0000