| Message ID | 20210928154143.2106903-1-arnd@kernel.org |
|---|---|
| Headers | show |
| Series | ARM: randconfig build fixes | expand |
On Tue, 28 Sep 2021, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > For platforms that are not yet converted to ARCH_MULTIPLATFORM, > we can disable CONFIG_ARM_PATCH_PHYS_VIRT, which in turn requires > setting a correct address here. > > As we actualy know what all the values are supposed to be based > on the old mach/memory.h header file contents (from git history), > we can just add them here. > > This also solves a problem in Kconfig where 'make randconfig' > fails to continue if no number is selected for a 'hex' option. > Users can still override the number at configuration time, e.g. > when the memory visible to the kernel starts at a nonstandard > address on some machine, but it should no longer be required > now. > > I originally posted this back in 2016, but the problem still > persists. The patch has gotten much simpler though, as almost > all platforms rely on ARM_PATCH_PHYS_VIRT now. > > Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> > Link: https://lore.kernel.org/linux-arm-kernel/1455804123-2526139-5-git-send-email-arnd@arndb.de/ > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > arch/arm/Kconfig | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 12a0bd4b315d..0d4f3e2d50ad 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -264,10 +264,12 @@ config PHYS_OFFSET > hex "Physical address of main memory" if MMU > depends on !ARM_PATCH_PHYS_VIRT > default DRAM_BASE if !MMU > - default 0x00000000 if ARCH_FOOTBRIDGE > + default 0x00000000 if ARCH_FOOTBRIDGE || ARCH_IXP4XX > default 0x10000000 if ARCH_OMAP1 || ARCH_RPC > - default 0x20000000 if ARCH_S5PV210 > - default 0xc0000000 if ARCH_SA1100 > + default 0x30000000 if ARCH_S3C24XX > + default 0xa0000000 if ARCH_IOP32X || ARCH_PXA > + default 0xc0000000 if ARCH_EP93XX || ARCH_SA1100 > + default 0 > help > Please provide the physical address corresponding to the > location of main memory in your system. > -- > 2.29.2 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
On Tue, Sep 28, 2021 at 5:42 PM Arnd Bergmann <arnd@kernel.org> wrote: > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index fc196421b2ce..12a0bd4b315d 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -431,7 +431,7 @@ config ARCH_PXA > > config ARCH_RPC > bool "RiscPC" > - depends on MMU This line was a botched rebase, it obviously has to stay here. Arnd > + depends on !CC_IS_CLANG || GCC_VERSION < 90100 > select ARCH_ACORN > select ARCH_MAY_HAVE_PC_FDC > select ARCH_SPARSEMEM_ENABLE > -- > 2.29.2 >
On Tue, Sep 28, 2021 at 8:42 AM Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > clang fails to build kernels with THUMB2 and FUNCTION_TRACER > enabled when there is any inline asm statement containing > the frame pointer register r7: > > arch/arm/mach-versatile/dcscb.c:95:2: error: inline asm clobber list contains reserved registers: R7 [-Werror,-Winline-asm] ^ This file no longer exists in tree? > arch/arm/mach-exynos/mcpm-exynos.c:154:2: error: inline asm clobber list contains reserved registers: R7 [-Werror,-Winline-asm] > arch/arm/probes/kprobes/actions-thumb.c:449:3: error: inline asm clobber list contains reserved registers: R7 [-Werror,-Winline-asm] > > Apparently gcc should also have warned about this, and the > configuration is actually invalid, though there is some > disagreement on the bug trackers about this. > > Link: https://bugs.llvm.org/show_bug.cgi?id=45826 > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986 > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> > --- > arch/arm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 0d4f3e2d50ad..7ea95bb40004 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -91,7 +91,7 @@ config ARM > select HAVE_FAST_GUP if ARM_LPAE > select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL > select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG > - select HAVE_FUNCTION_TRACER if !XIP_KERNEL > + select HAVE_FUNCTION_TRACER if !XIP_KERNEL && !(THUMB2_KERNEL && CC_IS_CLANG) > select HAVE_GCC_PLUGINS > select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7) > select HAVE_IRQ_TIME_ACCOUNTING > -- > 2.29.2 > >
On Tue, Sep 28, 2021 at 5:42 PM Arnd Bergmann <arnd@kernel.org> wrote: > From: Arnd Bergmann <arnd@arndb.de> > > On BE32 kernels, the __opcode_to_mem_thumb32() interface is intentionally > not defined, but it is referenced whenever runtime patching is enabled > for the kernel, which may be for ftrace, jump label, kprobes or kgdb: > > arch/arm/kernel/patch.c: In function '__patch_text_real': > arch/arm/kernel/patch.c:94:32: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration] > 94 | insn = __opcode_to_mem_thumb32(insn); > | ^~~~~~~~~~~~~~~~~~~~~~~ > > Since BE32 kernels never run Thumb2 code, we never end up using the > result of this call, so providing an extern declaration without > a definition makes it build correctly. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Looks good to me! Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Tue, Sep 28, 2021 at 5:42 PM Arnd Bergmann <arnd@kernel.org> wrote: > From: Arnd Bergmann <arnd@arndb.de> > > Both the decompressor code and the kasan logic try to override > the memcpy() and memmove() definitions, which leading to a clash > in a KASAN-enabled kernel with XZ decompression: > > arch/arm/boot/compressed/decompress.c:50:9: error: 'memmove' macro redefined [-Werror,-Wmacro-redefined] > #define memmove memmove > ^ > arch/arm/include/asm/string.h:59:9: note: previous definition is here > #define memmove(dst, src, len) __memmove(dst, src, len) > ^ > arch/arm/boot/compressed/decompress.c:51:9: error: 'memcpy' macro redefined [-Werror,-Wmacro-redefined] > #define memcpy memcpy > ^ > arch/arm/include/asm/string.h:58:9: note: previous definition is here > #define memcpy(dst, src, len) __memcpy(dst, src, len) > ^ > > Here we want the set of functions from the decompressor, so undefine > the other macros before the override. > > Fixes: d6d51a96c7d6 ("ARM: 9014/2: Replace string mem* functions for KASan") > Fixes: a7f464f3db93 ("ARM: 7001/2: Wire up support for the XZ decompressor") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Solves this, right? https://lore.kernel.org/lkml/202105091112.F5rmd4By-lkp@intel.com/ Can you put in a reported-by and Link: to this so we got it tracked? > #ifdef CONFIG_KERNEL_XZ > +#undef memmove > #define memmove memmove > +#undef memcpy > #define memcpy memcpy > #include "../../../../lib/decompress_unxz.c" > #endif That's clever, maybe drop a small comment in the code why we do this pretty unintuitive looking thing and how this works? Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Tue, Sep 28, 2021 at 5:42 PM Arnd Bergmann <arnd@kernel.org> wrote: > From: Arnd Bergmann <arnd@arndb.de> > > For platforms that are not yet converted to ARCH_MULTIPLATFORM, > we can disable CONFIG_ARM_PATCH_PHYS_VIRT, which in turn requires > setting a correct address here. > > As we actualy know what all the values are supposed to be based > on the old mach/memory.h header file contents (from git history), > we can just add them here. > > This also solves a problem in Kconfig where 'make randconfig' > fails to continue if no number is selected for a 'hex' option. > Users can still override the number at configuration time, e.g. > when the memory visible to the kernel starts at a nonstandard > address on some machine, but it should no longer be required > now. > > I originally posted this back in 2016, but the problem still > persists. The patch has gotten much simpler though, as almost > all platforms rely on ARM_PATCH_PHYS_VIRT now. > > Acked-by: Nicolas Pitre <nico@linaro.org> > Link: https://lore.kernel.org/linux-arm-kernel/1455804123-2526139-5-git-send-email-arnd@arndb.de/ > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> BTW thanks for this very nice cleanup patch set! Yours, Linus Walleij
On Tue, Sep 28, 2021 at 6:03 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Tue, Sep 28, 2021 at 5:42 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index fc196421b2ce..12a0bd4b315d 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -431,7 +431,7 @@ config ARCH_PXA > > > > config ARCH_RPC > > bool "RiscPC" > > - depends on MMU > > This line was a botched rebase, it obviously has to stay here. > > > + depends on !CC_IS_CLANG || GCC_VERSION < 90100 This line is also wrong, it needs to be '&&', not '||'. Arnd
On Tue, Sep 28, 2021 at 8:42 AM Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > We can currently build a multi-cpu enabled kernel that allows both ARMv4 > and ARMv5 CPUs, and also supports THUMB mode in user space. > > However, returning to user space in this configuration with the usr_ret > macro requires the use of the 'bx' instruction, which is refused by > the assembler: > > arch/arm/kernel/entry-armv.S: Assembler messages: > arch/arm/kernel/entry-armv.S:937: Error: selected processor does not support `bx lr' in ARM mode > arch/arm/kernel/entry-armv.S:960: Error: selected processor does not support `bx lr' in ARM mode > arch/arm/kernel/entry-armv.S:1003: Error: selected processor does not support `bx lr' in ARM mode > <instantiation>:2:2: note: instruction requires: armv4t > bx lr > > While it would be possible to handle this correctly in principle, doing so > seems to not be worth it, if we can simply avoid the problem by enforcing does `mov pc, lr` work here, with a preprocessor guard on CPU_32v4? Or better yet... If `ret` is just an assembler macro (arch/arm/include/asm/assembler.h#L449), then perhaps always just using `ret` would be preferable here? In that case, it looks like `usr_ret` could be outright replaced with just expansions of `ret`? Just spitballing ideas; like you said, maybe not worth fixing. > that a kernel supporting both ARMv4 and a later CPU architecture cannot > run THUMB binaries. > > This turned up while build-testing with clang; for some reason, > gcc never triggered the problem. I suspect this is a Clang's integrated assembler vs GAS difference (compiler irrelevant); clang's assembler is more strict that `bx lr` requires armvt (CPU_32v4T). Though I can reproduce that exact message in local testing with GAS: $ cat foo.s bx lr $ arm-linux-gnueabi-as -march=armv4 -c foo.s foo.s: Assembler messages: foo.s:1: Error: selected processor does not support `bx lr' in ARM mode $ arm-linux-gnueabi-as -march=armv4t -c foo.s $ arm-linux-gnueabi-objdump -dr a.out ... 00000000 <.text>: 0: e12fff1e bx lr 0: R_ARM_V4BX *ABS* The `<instantiation>:2:2` makes me think of inline asm. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> > --- > arch/arm/mm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig > index 82aa990c4180..58afba346729 100644 > --- a/arch/arm/mm/Kconfig > +++ b/arch/arm/mm/Kconfig > @@ -675,7 +675,7 @@ config ARM_PV_FIXUP > > config ARM_THUMB > bool "Support Thumb user binaries" if !CPU_THUMBONLY && EXPERT > - depends on CPU_THUMB_CAPABLE > + depends on CPU_THUMB_CAPABLE && !CPU_32v4 > default y > help > Say Y if you want to include kernel support for running user space > -- > 2.29.2 >
On Tue, 28 Sept 2021 at 17:42, Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > We can currently build a multi-cpu enabled kernel that allows both ARMv4 > and ARMv5 CPUs, and also supports THUMB mode in user space. > > However, returning to user space in this configuration with the usr_ret > macro requires the use of the 'bx' instruction, which is refused by > the assembler: > > arch/arm/kernel/entry-armv.S: Assembler messages: > arch/arm/kernel/entry-armv.S:937: Error: selected processor does not support `bx lr' in ARM mode > arch/arm/kernel/entry-armv.S:960: Error: selected processor does not support `bx lr' in ARM mode > arch/arm/kernel/entry-armv.S:1003: Error: selected processor does not support `bx lr' in ARM mode > <instantiation>:2:2: note: instruction requires: armv4t > bx lr > > While it would be possible to handle this correctly in principle, doing so > seems to not be worth it, if we can simply avoid the problem by enforcing > that a kernel supporting both ARMv4 and a later CPU architecture cannot > run THUMB binaries. > I had a quick look, and it seems that the only way to handle this correctly is to emit the BX instructions, and use code patching to change them into 'mov pc, <reg>' if the runtime detected CPU is not Thumb capable. The usual approach (emitting 'tst <reg>, #1; moveq pc, <reg>; bx lr') is not feasible here, since we run out of space in the kuser helper slots. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> > This turned up while build-testing with clang; for some reason, > gcc never triggered the problem. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > arch/arm/mm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig > index 82aa990c4180..58afba346729 100644 > --- a/arch/arm/mm/Kconfig > +++ b/arch/arm/mm/Kconfig > @@ -675,7 +675,7 @@ config ARM_PV_FIXUP > > config ARM_THUMB > bool "Support Thumb user binaries" if !CPU_THUMBONLY && EXPERT > - depends on CPU_THUMB_CAPABLE > + depends on CPU_THUMB_CAPABLE && !CPU_32v4 > default y > help > Say Y if you want to include kernel support for running user space > -- > 2.29.2 >
From: Arnd Bergmann <arnd@arndb.de> Hi Russell, This is a set of patches that address various problems building random configurations. Most of these are older and have been sitting in my collection of random fixes that I need to get back to. After the -Werror changes for v5.15, I did that and collected all the patches that fix something I actually run into. These are the arm32 specific ones that I think we could merge right away, either for v5.15 as a bugfix or for v5.16. Let me know if you have any objections. As the patches are mostly trivial, I would otherwise send them to your patch tracker once you've had time to take a look. There are a few more patches that I'm currently using, but those are the ones that that are not ready to be merged, either because they have been rejected before or because they are known to break something. Arnd Arnd Bergmann (13): ARM: RiscPC needs older gcc version ARM: patch: fix BE32 compilation ARM: remove duplicate memcpy() definition ARM: kprobes: address gcc -Wempty-body warning ARM: ARMv7-M uses BE-8, not BE-32 ARM: disallow CONFIG_THUMB with ARMv4 ARM: fix link warning with XIP + frame-pointer ARM: kprobes: fix arch_init_kprobes() prototype ARM: allow compile-testing without machine record ARM: only warn about XIP address when not compile testing ARM: kasan: work around LPAE build warning ARM: add CONFIG_PHYS_OFFSET default values [RFC] ARM: forbid ftrace with clang and thumb2_kernel Nick Desaulniers (1): ARM: use .arch directives instead of assembler command line flags arch/arm/Kconfig | 12 +++++++----- arch/arm/boot/compressed/Makefile | 2 -- arch/arm/boot/compressed/decompress.c | 2 ++ arch/arm/common/Makefile | 2 -- arch/arm/common/mcpm_head.S | 2 ++ arch/arm/common/vlock.S | 2 ++ arch/arm/include/asm/opcodes.h | 9 +++++++-- arch/arm/kernel/Makefile | 2 -- arch/arm/kernel/hyp-stub.S | 2 ++ arch/arm/kernel/swp_emulate.c | 1 + arch/arm/kernel/vmlinux-xip.lds.S | 8 +++++++- arch/arm/kernel/vmlinux.lds.S | 2 ++ arch/arm/lib/Makefile | 4 ---- arch/arm/lib/delay-loop.S | 4 ++++ arch/arm/mach-at91/Makefile | 3 --- arch/arm/mach-at91/pm_suspend.S | 4 ++++ arch/arm/mach-imx/Makefile | 3 --- arch/arm/mach-imx/headsmp.S | 2 ++ arch/arm/mach-imx/resume-imx6.S | 2 ++ arch/arm/mach-imx/suspend-imx6.S | 2 ++ arch/arm/mach-mvebu/Makefile | 3 --- arch/arm/mach-mvebu/coherency_ll.S | 1 + arch/arm/mach-mvebu/pmsu.c | 1 + arch/arm/mach-npcm/Makefile | 2 -- arch/arm/mach-npcm/headsmp.S | 2 ++ arch/arm/mm/Kconfig | 4 ++-- arch/arm/mm/Makefile | 15 --------------- arch/arm/mm/abort-ev6.S | 1 + arch/arm/mm/abort-ev7.S | 1 + arch/arm/mm/cache-v6.S | 2 ++ arch/arm/mm/cache-v7.S | 2 ++ arch/arm/mm/cache-v7m.S | 2 ++ arch/arm/mm/copypage-feroceon.c | 1 + arch/arm/mm/kasan_init.c | 2 +- arch/arm/mm/proc-v6.S | 2 ++ arch/arm/mm/proc-v7-2level.S | 2 ++ arch/arm/mm/proc-v7.S | 2 ++ arch/arm/mm/tlb-v6.S | 2 ++ arch/arm/mm/tlb-v7.S | 2 ++ arch/arm/probes/kprobes/core.c | 2 +- arch/arm/probes/kprobes/test-core.h | 2 +- drivers/memory/Makefile | 2 -- drivers/memory/ti-emif-sram-pm.S | 1 + 43 files changed, 75 insertions(+), 51 deletions(-)