* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Alexander Dahl @ 2021-05-03 7:34 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Albert Ou, Catalin Marinas, Arnd Bergmann,
Linux Kbuild mailing list, Greg Kroah-Hartman, Masahiro Yamada,
Jonathan Corbet, Linux Doc Mailing List, linux-kernel,
Miguel Ojeda, Will Deacon, Palmer Dabbelt, Paul Walmsley,
Joe Perches, Paul Mackerras, linux-riscv, Miguel Ojeda,
Linus Torvalds, Linux ARM, linuxppc-dev
In-Reply-To: <20210502223007.GZ1847222@casper.infradead.org>
Hei hei,
Am Sun, May 02, 2021 at 11:30:07PM +0100 schrieb Matthew Wilcox:
> On Sun, May 02, 2021 at 02:08:31PM -0700, Linus Torvalds wrote:
> > What is relevant is what version of gcc various distributions actually
> > have reasonably easily available, and how old and relevant the
> > distributions are. We did decide that (just as an example) RHEL 7 was
> > too old to worry about when we updated the gcc version requirement
> > last time.
> >
> > Last year, Arnd and Kirill (maybe others were involved too) made a
> > list of distros and older gcc versions. But I don't think anybody
> > actually _maintains_ such a list. It would be perhaps interesting to
> > have some way to check what compiler versions are being offered by
> > different distros.
>
> fwiw, Debian 9 aka Stretch released June 2017 had gcc 6.3
> Debian 10 aka Buster released June 2019 had gcc 7.4 *and* 8.3.
> Debian 8 aka Jessie had gcc-4.8.4 and gcc-4.9.2.
>
> So do we care about people who haven't bothered to upgrade userspace
> since 2017? If so, we can't go past 4.9.
Desktops and servers are all nice, however I just want to make you
aware, there are embedded users forced to stick to older cross
toolchains for different reasons as well, e.g. in industrial
environment. :-)
This is no show stopper for us, I just wanted to let you be aware.
Greets
Alex
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Joe Perches @ 2021-05-03 8:54 UTC (permalink / raw)
To: Alexander Dahl, Matthew Wilcox
Cc: Albert Ou, Catalin Marinas, Arnd Bergmann,
Linux Kbuild mailing list, Greg Kroah-Hartman, Masahiro Yamada,
Jonathan Corbet, Linux Doc Mailing List, linux-kernel,
Miguel Ojeda, Will Deacon, Palmer Dabbelt, Paul Walmsley,
Miguel Ojeda, Paul Mackerras, linux-riscv, linuxppc-dev,
Linus Torvalds, Linux ARM
In-Reply-To: <YI+nhMcPSTs/5Ydp@ada-deb-carambola.ifak-system.com>
On Mon, 2021-05-03 at 09:34 +0200, Alexander Dahl wrote:
> Desktops and servers are all nice, however I just want to make you
> aware, there are embedded users forced to stick to older cross
> toolchains for different reasons as well, e.g. in industrial
> environment. :-)
In your embedded case, what kernel version do you use?
For older toolchains, unless it's kernel version 5.13+,
it wouldn't matter.
And all the supported architectures have gcc 10.3 available at
http://cdn.kernel.org/pub/tools/crosstool/
^ permalink raw reply
* [PATCH v3] powerpc/64s/radix: Enable huge vmalloc mappings
From: Nicholas Piggin @ 2021-05-03 9:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
This reduces TLB misses by nearly 30x on a `git diff` workload on a
2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%, due
to vfs hashes being allocated with 2MB pages.
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
Since v2:
- Fix ppc32 compile bug.
Since v1:
- Don't define MODULES_VADDR which has some other side effect (e.g.,
ptdump).
- Fixed (hopefully) kbuild warning.
- Keep __vmalloc_node_range call on 3 lines.
.../admin-guide/kernel-parameters.txt | 2 ++
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/module.c | 18 +++++++++++++-----
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 1c0a3cf6fcc9..1be38b25c485 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3250,6 +3250,8 @@
nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
+ nohugevmalloc [PPC] Disable kernel huge vmalloc mappings.
+
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1e6230bea09d..c547a9d6a2dd 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -185,6 +185,7 @@ config PPC
select GENERIC_VDSO_TIME_NS
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 && PPC_RADIX_MMU
+ select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index fab84024650c..3f35c8d20be7 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -8,6 +8,7 @@
#include <linux/moduleloader.h>
#include <linux/err.h>
#include <linux/vmalloc.h>
+#include <linux/mm.h>
#include <linux/bug.h>
#include <asm/module.h>
#include <linux/uaccess.h>
@@ -88,17 +89,22 @@ int module_finalize(const Elf_Ehdr *hdr,
return 0;
}
-#ifdef MODULES_VADDR
static __always_inline void *
__module_alloc(unsigned long size, unsigned long start, unsigned long end)
{
- return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL,
- PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
- __builtin_return_address(0));
+ /*
+ * Don't do huge page allocations for modules yet until more testing
+ * is done. STRICT_MODULE_RWX may require extra work to support this
+ * too.
+ */
+ return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL, PAGE_KERNEL_EXEC,
+ VM_FLUSH_RESET_PERMS | VM_NO_HUGE_VMAP,
+ NUMA_NO_NODE, __builtin_return_address(0));
}
void *module_alloc(unsigned long size)
{
+#ifdef MODULES_VADDR
unsigned long limit = (unsigned long)_etext - SZ_32M;
void *ptr = NULL;
@@ -112,5 +118,7 @@ void *module_alloc(unsigned long size)
ptr = __module_alloc(size, MODULES_VADDR, MODULES_END);
return ptr;
-}
+#else
+ return __module_alloc(size, VMALLOC_START, VMALLOC_END);
#endif
+}
--
2.23.0
^ permalink raw reply related
* Re: [PATCH v3] powerpc/64s/radix: Enable huge vmalloc mappings
From: Christophe Leroy @ 2021-05-03 9:22 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20210503091755.613393-1-npiggin@gmail.com>
Le 03/05/2021 à 11:17, Nicholas Piggin a écrit :
> This reduces TLB misses by nearly 30x on a `git diff` workload on a
> 2-node POWER9 (59,800 -> 2,100) and reduces CPU cycles by 0.54%, due
> to vfs hashes being allocated with 2MB pages.
>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> Since v2:
> - Fix ppc32 compile bug.
>
> Since v1:
> - Don't define MODULES_VADDR which has some other side effect (e.g.,
> ptdump).
> - Fixed (hopefully) kbuild warning.
> - Keep __vmalloc_node_range call on 3 lines.
>
> .../admin-guide/kernel-parameters.txt | 2 ++
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/kernel/module.c | 18 +++++++++++++-----
> 3 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 1c0a3cf6fcc9..1be38b25c485 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -3250,6 +3250,8 @@
>
> nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
>
> + nohugevmalloc [PPC] Disable kernel huge vmalloc mappings.
> +
> nosmt [KNL,S390] Disable symmetric multithreading (SMT).
> Equivalent to smt=1.
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 1e6230bea09d..c547a9d6a2dd 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -185,6 +185,7 @@ config PPC
> select GENERIC_VDSO_TIME_NS
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 && PPC_RADIX_MMU
> + select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
> select HAVE_ARCH_JUMP_LABEL
> select HAVE_ARCH_JUMP_LABEL_RELATIVE
> select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14
> diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
> index fab84024650c..3f35c8d20be7 100644
> --- a/arch/powerpc/kernel/module.c
> +++ b/arch/powerpc/kernel/module.c
> @@ -8,6 +8,7 @@
> #include <linux/moduleloader.h>
> #include <linux/err.h>
> #include <linux/vmalloc.h>
> +#include <linux/mm.h>
> #include <linux/bug.h>
> #include <asm/module.h>
> #include <linux/uaccess.h>
> @@ -88,17 +89,22 @@ int module_finalize(const Elf_Ehdr *hdr,
> return 0;
> }
>
> -#ifdef MODULES_VADDR
> static __always_inline void *
> __module_alloc(unsigned long size, unsigned long start, unsigned long end)
> {
> - return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL,
> - PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
> - __builtin_return_address(0));
> + /*
> + * Don't do huge page allocations for modules yet until more testing
> + * is done. STRICT_MODULE_RWX may require extra work to support this
> + * too.
> + */
> + return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL, PAGE_KERNEL_EXEC,
> + VM_FLUSH_RESET_PERMS | VM_NO_HUGE_VMAP,
> + NUMA_NO_NODE, __builtin_return_address(0));
> }
>
> void *module_alloc(unsigned long size)
> {
> +#ifdef MODULES_VADDR
> unsigned long limit = (unsigned long)_etext - SZ_32M;
> void *ptr = NULL;
>
> @@ -112,5 +118,7 @@ void *module_alloc(unsigned long size)
> ptr = __module_alloc(size, MODULES_VADDR, MODULES_END);
>
> return ptr;
> -}
> +#else
> + return __module_alloc(size, VMALLOC_START, VMALLOC_END);
> #endif
> +}
>
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Arnd Bergmann @ 2021-05-03 9:25 UTC (permalink / raw)
To: Matthew Wilcox, Linus Torvalds, Segher Boessenkool, Joe Perches,
Miguel Ojeda, Masahiro Yamada, Albert Ou, Arnd Bergmann,
Linux Kbuild mailing list, Greg Kroah-Hartman, Jonathan Corbet,
Linux Doc Mailing List, linux-kernel, Palmer Dabbelt,
Paul Walmsley, Catalin Marinas, Miguel Ojeda, Paul Mackerras,
linux-riscv, linuxppc-dev, Will Deacon, Linux ARM
In-Reply-To: <YI+nhMcPSTs/5Ydp@ada-deb-carambola.ifak-system.com>
On Mon, May 3, 2021 at 9:35 AM Alexander Dahl <ada@thorsis.com> wrote:
>
> Desktops and servers are all nice, however I just want to make you
> aware, there are embedded users forced to stick to older cross
> toolchains for different reasons as well, e.g. in industrial
> environment. :-)
>
> This is no show stopper for us, I just wanted to let you be aware.
Can you be more specific about what scenarios you are thinking of,
what the motivations are for using an old compiler with a new kernel
on embedded systems, and what you think a realistic maximum
time would be between compiler updates?
One scenario that I've seen previously is where user space and
kernel are built together as a source based distribution (OE, buildroot,
openwrt, ...), and the compiler is picked to match the original sources
of the user space because that is best tested, but the same compiler
then gets used to build the kernel as well because that is the default
in the build environment.
There are two problems I see with this logic:
- Running the latest kernel to avoid security problems is of course
a good idea, but if one runs that with ten year old user space that
is never updated, the system is likely to end up just as insecure.
Not all bugs are in the kernel.
- The same logic that applies to ancient user space staying with
an ancient compiler (it's better tested in this combination) also
applies to the kernel: running the latest kernel on an old compiler
is something that few people test, and tends to run into more bugs
than using the compiler that other developers used to test that
kernel.
Arnd
^ permalink raw reply
* Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels
From: Michal Suchánek @ 2021-05-03 9:34 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20210503071116.GI6564@kitsune.suse.cz>
On Mon, May 03, 2021 at 09:11:16AM +0200, Michal Suchánek wrote:
> On Mon, May 03, 2021 at 10:58:33AM +1000, Nicholas Piggin wrote:
> > Excerpts from Michal Suchánek's message of May 3, 2021 2:57 am:
> > > On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote:
> > >> Provide an option to use ELFv2 ABI for big endian builds. This works on
> > >> GCC and clang (since 2014). It is less well tested and supported by the
> > >> GNU toolchain, but it can give some useful advantages of the ELFv2 ABI
> > >> for BE (e.g., less stack usage). Some distros even build BE ELFv2
> > >> userspace.
> > >
> > > Fixes BTFID failure on BE for me and the ELF ABIv2 kernel boots.
> >
> > What's the BTFID failure? Anything we can do to fix it on the v1 ABI or
> > at least make it depend on BUILD_ELF_V2?
>
> Looks like symbols are prefixed with a dot in ABIv1 and BTFID tool is
> not aware of that. It can be disabled on ABIv1 easily.
>
> Thanks
>
> Michal
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 678c13967580..e703c26e9b80 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -305,6 +305,7 @@ config DEBUG_INFO_BTF
> bool "Generate BTF typeinfo"
> depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
> depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
> + depends on !PPC64 || BUILD_ELF_V2
> help
> Generate deduplicated BTF type information from DWARF debug info.
> Turning this on expects presence of pahole tool, which will convert
>
> >
> > >
> > > Tested-by: Michal Suchánek <msuchanek@suse.de>
> > >
> > > Also can we enable mprofile on BE now?
> > >
> > > I don't see anything endian-specific in the mprofile code at a glance
> > > but don't have any idea how to test it.
> >
> > AFAIK it's just a different ABI for the _mcount call so just running
> > some ftrace and ftrace with call graph should test it reasonably well.
It does not crash and burn but there are some regressions from LE to BE
on the ftrace kernel selftest:
--- ftraceLE.txt 2021-05-03 11:19:14.830000000 +0200
+++ ftraceBE.txt 2021-05-03 11:27:24.770000000 +0200
@@ -7,8 +7,8 @@
[n] Change the ringbuffer size [PASS]
[n] Snapshot and tracing setting [PASS]
[n] trace_pipe and trace_marker [PASS]
-[n] Test ftrace direct functions against tracers [UNRESOLVED]
-[n] Test ftrace direct functions against kprobes [UNRESOLVED]
+[n] Test ftrace direct functions against tracers [FAIL]
+[n] Test ftrace direct functions against kprobes [FAIL]
[n] Generic dynamic event - add/remove kprobe events [PASS]
[n] Generic dynamic event - add/remove synthetic events [PASS]
[n] Generic dynamic event - selective clear (compatibility) [PASS]
@@ -16,10 +16,10 @@
[n] event tracing - enable/disable with event level files [PASS]
[n] event tracing - restricts events based on pid notrace filtering [PASS]
[n] event tracing - restricts events based on pid [PASS]
-[n] event tracing - enable/disable with subsystem level files [PASS]
+[n] event tracing - enable/disable with subsystem level files [FAIL]
[n] event tracing - enable/disable with top level files [PASS]
-[n] Test trace_printk from module [UNRESOLVED]
-[n] ftrace - function graph filters with stack tracer [PASS]
+[n] Test trace_printk from module [FAIL]
+[n] ftrace - function graph filters with stack tracer [FAIL]
[n] ftrace - function graph filters [PASS]
[n] ftrace - function trace with cpumask [PASS]
[n] ftrace - test for function event triggers [PASS]
@@ -27,7 +27,7 @@
[n] ftrace - function pid notrace filters [PASS]
[n] ftrace - function pid filters [PASS]
[n] ftrace - stacktrace filter command [PASS]
-[n] ftrace - function trace on module [UNRESOLVED]
+[n] ftrace - function trace on module [FAIL]
[n] ftrace - function profiler with function tracing [PASS]
[n] ftrace - function profiling [PASS]
[n] ftrace - test reading of set_ftrace_filter [PASS]
@@ -44,10 +44,10 @@
[n] Kprobe event argument syntax [PASS]
[n] Kprobe dynamic event with arguments [PASS]
[n] Kprobes event arguments with types [PASS]
-[n] Kprobe event user-memory access [UNSUPPORTED]
+[n] Kprobe event user-memory access [FAIL]
[n] Kprobe event auto/manual naming [PASS]
[n] Kprobe dynamic event with function tracer [PASS]
-[n] Kprobe dynamic event - probing module [UNRESOLVED]
+[n] Kprobe dynamic event - probing module [FAIL]
[n] Create/delete multiprobe on kprobe event [PASS]
[n] Kprobe event parser error log check [PASS]
[n] Kretprobe dynamic event with arguments [PASS]
@@ -57,11 +57,11 @@
[n] Kprobe events - probe points [PASS]
[n] Kprobe dynamic event - adding and removing [PASS]
[n] Uprobe event parser error log check [PASS]
-[n] test for the preemptirqsoff tracer [UNSUPPORTED]
-[n] Meta-selftest: Checkbashisms [UNRESOLVED]
+[n] test for the preemptirqsoff tracer [FAIL]
+[n] Meta-selftest: Checkbashisms [FAIL]
[n] Test wakeup RT tracer [PASS]
[n] Test wakeup tracer [PASS]
-[n] event trigger - test inter-event histogram trigger expected fail actions [XFAIL]
+[n] event trigger - test inter-event histogram trigger expected fail actions [FAIL]
[n] event trigger - test field variable support [PASS]
[n] event trigger - test inter-event combined histogram trigger [PASS]
[n] event trigger - test multiple actions on hist trigger [PASS]
@@ -96,7 +96,8 @@
[n] (instance) event tracing - enable/disable with event level files [PASS]
[n] (instance) event tracing - restricts events based on pid notrace filtering [PASS]
[n] (instance) event tracing - restricts events based on pid [PASS]
-[n] (instance) event tracing - enable/disable with subsystem level files [PASS]
+[n] (instance) event tracing - enable/disable with subsystem level files [FAIL]
+rmdir: failed to remove '/sys/kernel/tracing/instances/ftracetest.mceByV': Device or resource busy
[n] (instance) ftrace - test for function event triggers [PASS]
[n] (instance) ftrace - function pid notrace filters [PASS]
[n] (instance) ftrace - function pid filters [PASS]
I needed to add a test timeout to get this far because
"event tracing - enable/disable with subsystem level files" gets stuck.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Kirill A. Shutemov @ 2021-05-03 9:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Albert Ou, Catalin Marinas, Arnd Bergmann,
Linux Kbuild mailing list, Greg Kroah-Hartman, Masahiro Yamada,
Jonathan Corbet, Linux Doc Mailing List, linux-kernel,
Miguel Ojeda, Will Deacon, Palmer Dabbelt, Paul Walmsley,
Joe Perches, Paul Mackerras, linux-riscv, Miguel Ojeda,
linuxppc-dev, Linux ARM
In-Reply-To: <CAHk-=wjGJskk5EwnDCccs6DcLytE2yx76+P_W-n1-B5zq0M3KA@mail.gmail.com>
On Sun, May 02, 2021 at 02:08:31PM -0700, Linus Torvalds wrote:
> Last year, Arnd and Kirill (maybe others were involved too) made a
> list of distros and older gcc versions. But I don't think anybody
> actually _maintains_ such a list.
Distrowatch does. I used it for checking. But you need to check it per
distro. For Debian it would be here:
https://distrowatch.com/table.php?distribution=debian
--
Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Arnd Bergmann @ 2021-05-03 9:57 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Albert Ou, Catalin Marinas, Will Deacon,
Linux Kbuild mailing list, Greg Kroah-Hartman, Masahiro Yamada,
Jonathan Corbet, Linux Doc Mailing List, linux-kernel,
Miguel Ojeda, Palmer Dabbelt, Paul Walmsley, Joe Perches,
Paul Mackerras, linux-riscv, Miguel Ojeda, Linus Torvalds,
Linux ARM, linuxppc-dev
In-Reply-To: <20210503004457.GI10366@gate.crashing.org>
On Mon, May 3, 2021 at 2:44 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Sun, May 02, 2021 at 02:23:01PM -0700, Joe Perches wrote:
> > On Sun, 2021-05-02 at 15:32 -0500, Segher Boessenkool wrote:
> > > On Sun, May 02, 2021 at 01:00:28PM -0700, Joe Perches wrote:
> > []
> > > > Perhaps 8 might be best as that has a __diag warning control mechanism.
> > >
> > > I have no idea what you mean?
> >
> > ? read the last bit of compiler-gcc.h
>
> Ah, you mean
> #pragma GCC diagnostic
> (which has existed since GCC 4.2). Does anything in this __diag stuff
> require GCC 8? Other than that this is hardcoded here :-)
The '8' was just a kernel thing, we made it configurable to have version
specific warnings, and I have a header file that adds these macros
for all supported compilers, but the version that is in mainline only does
it for gcc-8 or later.
Early compilers only supported "#pragma GCC diagnostic", but I think
even gcc-4.6 supported the _Pragma() syntax that lets you do it inside
of a macro.
It's something we should improve with plumbing on top, e.g. I want
a macro that lets you locally turn off both -Woverride-init on gcc
and -Winitializer-overrides on clang. It's not a reason to mandate
a newer compiler though.
Arnd
^ permalink raw reply
* [PATCH] ibmvnic: remove default label from to_string switch
From: Michal Suchanek @ 2021-05-03 10:23 UTC (permalink / raw)
To: netdev
Cc: Sukadev Bhattiprolu, linux-kernel, Thomas Falcon, Paul Mackerras,
Dany Madden, Jakub Kicinski, Michal Suchanek, linuxppc-dev,
David S. Miller
This way the compiler warns when a new value is added to the enum but
not the string transation like:
drivers/net/ethernet/ibm/ibmvnic.c: In function 'adapter_state_to_string':
drivers/net/ethernet/ibm/ibmvnic.c:832:2: warning: enumeration value 'VNIC_FOOBAR' not handled in switch [-Wswitch]
switch (state) {
^~~~~~
drivers/net/ethernet/ibm/ibmvnic.c: In function 'reset_reason_to_string':
drivers/net/ethernet/ibm/ibmvnic.c:1935:2: warning: enumeration value 'VNIC_RESET_FOOBAR' not handled in switch [-Wswitch]
switch (reason) {
^~~~~~
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
drivers/net/ethernet/ibm/ibmvnic.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 5788bb956d73..4d439413f6d9 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -846,9 +846,8 @@ static const char *adapter_state_to_string(enum vnic_state state)
return "REMOVING";
case VNIC_REMOVED:
return "REMOVED";
- default:
- return "UNKNOWN";
}
+ return "UNKNOWN";
}
static int ibmvnic_login(struct net_device *netdev)
@@ -1946,9 +1945,8 @@ static const char *reset_reason_to_string(enum ibmvnic_reset_reason reason)
return "TIMEOUT";
case VNIC_RESET_CHANGE_PARAM:
return "CHANGE_PARAM";
- default:
- return "UNKNOWN";
}
+ return "UNKNOWN";
}
/*
--
2.26.2
^ permalink raw reply related
* [PATCH v3] powerpc/64: Option to use ELFv2 ABI for big-endian kernels
From: Nicholas Piggin @ 2021-05-03 11:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Michal Suchánek, Nicholas Piggin
Provide an option to build big-endian kernels using the ELFv2 ABI. This
works on GCC only so far, although it is rumored to work with clang
that's not been tested yet.
This can give big-endian kernels some useful advantages of the ELFv2 ABI
(e.g., less stack usage, -mprofile-kernel, better compatibility with bpf
tools).
BE+ELFv2 is not officially supported by the GNU toolchain, but it works
fine in testing and has been used by some userspace for some time (e.g.,
Void Linux).
Tested-by: Michal Suchánek <msuchanek@suse.de>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
I didn't add the -mprofile-kernel change but I think it would be a good
one that can be merged independently if it works.
Since v2:
- Rebased, tweaked changelog.
- Changed ELF_V2 to ELF_V2_ABI in config options, to be clearer.
Since v1:
- Improved the override flavour name suggested by Segher.
- Improved changelog wording.
arch/powerpc/Kconfig | 22 ++++++++++++++++++++++
arch/powerpc/Makefile | 18 ++++++++++++------
arch/powerpc/boot/Makefile | 4 +++-
arch/powerpc/kernel/vdso64/Makefile | 13 +++++++++++++
drivers/crypto/vmx/Makefile | 8 ++++++--
drivers/crypto/vmx/ppc-xlate.pl | 10 ++++++----
6 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1e6230bea09d..d3f78d3d574d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -160,6 +160,7 @@ config PPC
select ARCH_WEAK_RELEASE_ACQUIRE
select BINFMT_ELF
select BUILDTIME_TABLE_SORT
+ select PPC64_BUILD_ELF_V2_ABI if PPC64 && CPU_LITTLE_ENDIAN
select CLONE_BACKWARDS
select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
select DMA_OPS if PPC64
@@ -568,6 +569,27 @@ config KEXEC_FILE
config ARCH_HAS_KEXEC_PURGATORY
def_bool KEXEC_FILE
+config PPC64_BUILD_ELF_V2_ABI
+ bool
+
+config PPC64_BUILD_BIG_ENDIAN_ELF_V2_ABI
+ bool "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)"
+ depends on PPC64 && CPU_BIG_ENDIAN && EXPERT
+ depends on CC_IS_GCC && LD_VERSION >= 22400
+ default n
+ select PPC64_BUILD_ELF_V2_ABI
+ help
+ This builds the kernel image using the "Power Architecture 64-Bit ELF
+ V2 ABI Specification", which has a reduced stack overhead and faster
+ function calls. This internal kernel ABI option does not affect
+ userspace compatibility.
+
+ The V2 ABI is standard for 64-bit little-endian, but for big-endian
+ it is less well tested by kernel and toolchain. However some distros
+ build userspace this way, and it can produce a functioning kernel.
+
+ This requires GCC and binutils 2.24 or newer.
+
config RELOCATABLE
bool "Build a relocatable kernel"
depends on PPC64 || (FLATMEM && (44x || FSL_BOOKE))
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 3212d076ac6a..b90b5cb799aa 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -91,10 +91,14 @@ endif
ifdef CONFIG_PPC64
ifndef CONFIG_CC_IS_CLANG
-cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
-cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mcall-aixdesc)
-aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
-aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2
+ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
+cflags-y += $(call cc-option,-mabi=elfv2)
+aflags-y += $(call cc-option,-mabi=elfv2)
+else
+cflags-y += $(call cc-option,-mabi=elfv1)
+cflags-y += $(call cc-option,-mcall-aixdesc)
+aflags-y += $(call cc-option,-mabi=elfv1)
+endif
endif
endif
@@ -142,15 +146,17 @@ endif
CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no)
ifndef CONFIG_CC_IS_CLANG
-ifdef CONFIG_CPU_LITTLE_ENDIAN
-CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
+ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
+CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
else
+# Keep these in synch with arch/powerpc/kernel/vdso64/Makefile
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc)
AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
endif
endif
+
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call cc-option,-mminimal-toc))
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 2b8da923ceca..be84a72f8258 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -40,6 +40,9 @@ BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
ifdef CONFIG_PPC64_BOOT_WRAPPER
BOOTCFLAGS += -m64
+ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
+BOOTCFLAGS += $(call cc-option,-mabi=elfv2)
+endif
else
BOOTCFLAGS += -m32
endif
@@ -50,7 +53,6 @@ ifdef CONFIG_CPU_BIG_ENDIAN
BOOTCFLAGS += -mbig-endian
else
BOOTCFLAGS += -mlittle-endian
-BOOTCFLAGS += $(call cc-option,-mabi=elfv2)
endif
BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc
diff --git a/arch/powerpc/kernel/vdso64/Makefile b/arch/powerpc/kernel/vdso64/Makefile
index 2813e3f98db6..d783c07e558f 100644
--- a/arch/powerpc/kernel/vdso64/Makefile
+++ b/arch/powerpc/kernel/vdso64/Makefile
@@ -25,6 +25,19 @@ KCOV_INSTRUMENT := n
UBSAN_SANITIZE := n
KASAN_SANITIZE := n
+# Always build vdso64 with ELFv1 ABI for BE kernels
+ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
+ifdef CONFIG_CPU_BIG_ENDIAN
+KBUILD_CFLAGS := $(filter-out -mabi=elfv2,$(KBUILD_CFLAGS))
+KBUILD_AFLAGS := $(filter-out -mabi=elfv2,$(KBUILD_AFLAGS))
+
+# These are derived from arch/powerpc/Makefile
+KBUILD_CFLAGS += $(call cc-option,-mabi=elfv1)
+KBUILD_CFLAGS += $(call cc-option,-mcall-aixdesc)
+KBUILD_AFLAGS += $(call cc-option,-mabi=elfv1)
+endif
+endif
+
ccflags-y := -shared -fno-common -fno-builtin -nostdlib \
-Wl,-soname=linux-vdso64.so.1 -Wl,--hash-style=both
asflags-y := -D__VDSO64__ -s
diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile
index 709670d2b553..d9ccf9fc3483 100644
--- a/drivers/crypto/vmx/Makefile
+++ b/drivers/crypto/vmx/Makefile
@@ -5,18 +5,22 @@ vmx-crypto-objs := vmx.o aesp8-ppc.o ghashp8-ppc.o aes.o aes_cbc.o aes_ctr.o aes
ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
override flavour := linux-ppc64le
else
+ifdef CONFIG_PPC64_BUILD_ELF_V2_ABI
+override flavour := linux-ppc64-elfv2
+else
override flavour := linux-ppc64
endif
+endif
quiet_cmd_perl = PERL $@
cmd_perl = $(PERL) $(<) $(flavour) > $(@)
targets += aesp8-ppc.S ghashp8-ppc.S
-$(obj)/aesp8-ppc.S: $(src)/aesp8-ppc.pl FORCE
+$(obj)/aesp8-ppc.S: $(src)/aesp8-ppc.pl $(src)/ppc-xlate.pl FORCE
$(call if_changed,perl)
-$(obj)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl FORCE
+$(obj)/ghashp8-ppc.S: $(src)/ghashp8-ppc.pl $(src)/ppc-xlate.pl FORCE
$(call if_changed,perl)
clean-files := aesp8-ppc.S ghashp8-ppc.S
diff --git a/drivers/crypto/vmx/ppc-xlate.pl b/drivers/crypto/vmx/ppc-xlate.pl
index 36db2ef09e5b..b583898c11ae 100644
--- a/drivers/crypto/vmx/ppc-xlate.pl
+++ b/drivers/crypto/vmx/ppc-xlate.pl
@@ -9,6 +9,8 @@ open STDOUT,">$output" || die "can't open $output: $!";
my %GLOBALS;
my $dotinlocallabels=($flavour=~/linux/)?1:0;
+my $elfv2abi=(($flavour =~ /linux-ppc64le/) or ($flavour =~ /linux-ppc64-elfv2/))?1:0;
+my $dotfunctions=($elfv2abi=~1)?0:1;
################################################################
# directives which need special treatment on different platforms
@@ -40,7 +42,7 @@ my $globl = sub {
};
my $text = sub {
my $ret = ($flavour =~ /aix/) ? ".csect\t.text[PR],7" : ".text";
- $ret = ".abiversion 2\n".$ret if ($flavour =~ /linux.*64le/);
+ $ret = ".abiversion 2\n".$ret if ($elfv2abi);
$ret;
};
my $machine = sub {
@@ -56,8 +58,8 @@ my $size = sub {
if ($flavour =~ /linux/)
{ shift;
my $name = shift; $name =~ s|^[\.\_]||;
- my $ret = ".size $name,.-".($flavour=~/64$/?".":"").$name;
- $ret .= "\n.size .$name,.-.$name" if ($flavour=~/64$/);
+ my $ret = ".size $name,.-".($dotfunctions?".":"").$name;
+ $ret .= "\n.size .$name,.-.$name" if ($dotfunctions);
$ret;
}
else
@@ -142,7 +144,7 @@ my $vmr = sub {
# Some ABIs specify vrsave, special-purpose register #256, as reserved
# for system use.
-my $no_vrsave = ($flavour =~ /linux-ppc64le/);
+my $no_vrsave = ($elfv2abi);
my $mtspr = sub {
my ($f,$idx,$ra) = @_;
if ($idx == 256 && $no_vrsave) {
--
2.23.0
^ permalink raw reply related
* [PATCH] powerpc/64s: Make NMI record implicitly soft-masked code as irqs disabled
From: Nicholas Piggin @ 2021-05-03 11:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Cédric Le Goater, Nicholas Piggin
scv support introduced the notion of code that implicitly soft-masks
irqs due to the instruction addresses. This is required because scv
enters the kernel with MSR[EE]=1.
If a NMI (including soft-NMI) interrupt hits when we are implicitly
soft-masked then its regs->softe does not reflect this because it is
derived from the explicit soft mask state (paca->irq_soft_mask). This
makes arch_irq_disabled_regs(regs) return false.
This can trigger a warning in the soft-NMI watchdog code (shown below).
Fix it by having NMI interrupts set regs->softe to disabled in case of
interrupting an implicit soft-masked region.
------------[ cut here ]------------
WARNING: CPU: 41 PID: 1103 at arch/powerpc/kernel/watchdog.c:259 soft_nmi_interrupt+0x3e4/0x5f0
CPU: 41 PID: 1103 Comm: (spawn) Not tainted
NIP: c000000000039534 LR: c000000000039234 CTR: c000000000009a00
REGS: c000007fffbcf940 TRAP: 0700 Not tainted
MSR: 9000000000021033 <SF,HV,ME,IR,DR,RI,LE> CR: 22042482 XER: 200400ad
CFAR: c000000000039260 IRQMASK: 3
GPR00: c000000000039204 c000007fffbcfbe0 c000000001d6c300 0000000000000003
GPR04: 00007ffffa45d078 0000000000000000 0000000000000008 0000000000000020
GPR08: 0000007ffd4e0000 0000000000000000 c000007ffffceb00 7265677368657265
GPR12: 9000000000009033 c000007ffffceb00 00000f7075bf4480 000000000000002a
GPR16: 00000f705745a528 00007ffffa45ddd8 00000f70574d0008 0000000000000000
GPR20: 00000f7075c58d70 00000f7057459c38 0000000000000001 0000000000000040
GPR24: 0000000000000000 0000000000000029 c000000001dae058 0000000000000029
GPR28: 0000000000000000 0000000000000800 0000000000000009 c000007fffbcfd60
NIP [c000000000039534] soft_nmi_interrupt+0x3e4/0x5f0
LR [c000000000039234] soft_nmi_interrupt+0xe4/0x5f0
Call Trace:
[c000007fffbcfbe0] [c000000000039204] soft_nmi_interrupt+0xb4/0x5f0 (unreliable)
[c000007fffbcfcf0] [c00000000000c0e8] soft_nmi_common+0x138/0x1c4
--- interrupt: 900 at end_real_trampolines+0x0/0x1000
NIP: c000000000003000 LR: 00007ca426adb03c CTR: 900000000280f033
REGS: c000007fffbcfd60 TRAP: 0900
MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 44042482 XER: 200400ad
CFAR: 00007ca426946020 IRQMASK: 0
GPR00: 00000000000000ad 00007ffffa45d050 00007ca426b07f00 0000000000000035
GPR04: 00007ffffa45d078 0000000000000000 0000000000000008 0000000000000020
GPR08: 0000000000000000 0000000000100000 0000000010000000 00007ffffa45d110
GPR12: 0000000000000001 00007ca426d4e680 00000f7075bf4480 000000000000002a
GPR16: 00000f705745a528 00007ffffa45ddd8 00000f70574d0008 0000000000000000
GPR20: 00000f7075c58d70 00000f7057459c38 0000000000000001 0000000000000040
GPR24: 0000000000000000 00000f7057473f68 0000000000000003 000000000000041b
GPR28: 00007ffffa45d4c4 0000000000000035 0000000000000000 00000f7057473f68
NIP [c000000000003000] end_real_trampolines+0x0/0x1000
LR [00007ca426adb03c] 0x7ca426adb03c
--- interrupt: 900
Instruction dump:
60000000 60000000 60420000 38600001 482b3ae5 60000000 e93f0138 a36d0008
7daa6b78 71290001 7f7907b4 4082fd34 <0fe00000> 4bfffd2c 60420000 ea6100a8
---[ end trace dc75f67d819779da ]---
Fixes: 118178e62e2e ("powerpc: move NMI entry/exit code into wrapper")
Reported-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/interrupt.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/include/asm/interrupt.h b/arch/powerpc/include/asm/interrupt.h
index 44cde2e129b8..299e51337aca 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -222,6 +222,13 @@ static inline void interrupt_nmi_enter_prepare(struct pt_regs *regs, struct inte
local_paca->irq_soft_mask = IRQS_ALL_DISABLED;
local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
+ if (IS_ENABLED(CONFIG_PPC_BOOK3S_64) && !(regs->msr & MSR_PR) &&
+ regs->nip < (unsigned long)__end_interrupts) {
+ /* Kernel code running below __end_interrupts is implicitly
+ * soft-masked */
+ regs->softe = IRQS_ALL_DISABLED;
+ }
+
/* Don't do any per-CPU operations until interrupt state is fixed */
if (nmi_disables_ftrace(regs)) {
--
2.23.0
^ permalink raw reply related
* [PATCH] powerpc/pseries: Enable hardlockup watchdog for PowerVM partitions
From: Nicholas Piggin @ 2021-05-03 11:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
PowerVM will not arbitrarily oversubscribe or stop guests, page out the
guest kernel text to a NFS volume connected by carrier pigeon to abacus
based storage, etc., as a KVM host might. So PowerVM guests are not
likely to be killed by the hard lockup watchdog in normal operation,
even with shared processor LPARs which still get a minimum allotment of
CPU time.
Enable the hard lockup detector by default on !KVM guests, which we will
assume is PowerVM. It has been useful in finding problems on bare metal
kernels.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/setup_64.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index b779d25761cf..c0e234456863 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -939,15 +939,17 @@ u64 hw_nmi_get_sample_period(int watchdog_thresh)
* disable it by default. Book3S has a soft-nmi hardlockup detector based
* on the decrementer interrupt, so it does not suffer from this problem.
*
- * It is likely to get false positives in VM guests, so disable it there
- * by default too.
+ * It is likely to get false positives in KVM guests, so disable it there
+ * by default too. PowerVM will not stop or arbitrarily oversubscribe
+ * CPUs, but give a minimum regular allotment even with SPLPAR, so enable
+ * the detector for non-KVM guests, assume PowerVM.
*/
static int __init disable_hardlockup_detector(void)
{
#ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF
hardlockup_detector_disable();
#else
- if (firmware_has_feature(FW_FEATURE_LPAR))
+ if (is_kvm_guest())
hardlockup_detector_disable();
#endif
--
2.23.0
^ permalink raw reply related
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Arnd Bergmann @ 2021-05-03 11:35 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Albert Ou, Catalin Marinas, Linux Kbuild mailing list,
Greg Kroah-Hartman, Masahiro Yamada, Jonathan Corbet,
Linux Doc Mailing List, linux-kernel, Miguel Ojeda, Will Deacon,
Palmer Dabbelt, Paul Walmsley, Joe Perches, Paul Mackerras,
linux-riscv, Miguel Ojeda, Linus Torvalds, Linux ARM,
linuxppc-dev
In-Reply-To: <20210502223007.GZ1847222@casper.infradead.org>
On Mon, May 3, 2021 at 12:32 AM Matthew Wilcox <willy@infradead.org> wrote:
> On Sun, May 02, 2021 at 02:08:31PM -0700, Linus Torvalds wrote:
> > What is relevant is what version of gcc various distributions actually
> > have reasonably easily available, and how old and relevant the
> > distributions are. We did decide that (just as an example) RHEL 7 was
> > too old to worry about when we updated the gcc version requirement
> > last time.
> >
> > Last year, Arnd and Kirill (maybe others were involved too) made a
> > list of distros and older gcc versions. But I don't think anybody
> > actually _maintains_ such a list. It would be perhaps interesting to
> > have some way to check what compiler versions are being offered by
> > different distros.
>
> fwiw, Debian 9 aka Stretch released June 2017 had gcc 6.3
> Debian 10 aka Buster released June 2019 had gcc 7.4 *and* 8.3.
> Debian 8 aka Jessie had gcc-4.8.4 and gcc-4.9.2.
>
> So do we care about people who haven't bothered to upgrade userspace
> since 2017? If so, we can't go past 4.9.
I would argue that we shouldn't care about distros that are officially
end-of-life. Jessie support ended last July according to the official
Debian pages at https://wiki.debian.org/LTS.
It's a little harder for distros that are still officially supported, like the
RHEL7 case that Linus mentioned, Debian Stretch (gcc-6.3),
Slackware 14.2 (gcc-5.3), or Ubuntu 18.04 (gcc-7.3). For any of
these you could make the argument one way or the other: either
say we care as long as the distro cares, or the users that want
to build their own kernels can be reasonably expected to either
upgrade their distro or install a newer compiler manually.
Looking at the Debian case specifically, I see these numbers
from https://popcon.debian.org/:
testing/unstable: 16730
buster/stable: 113881
stretch/oldstable: 39147
jessie/oldoldstable: 19286
Assuming the numbers of users that installed popcon are
proportional to the actual number of users, that's still a large
chunk of people running stretch or older. Presumably,
these users are actually less likely to build their own kernels.
Arnd
^ permalink raw reply
* Re: [PATCH v3] powerpc/64: Option to use ELFv2 ABI for big-endian kernels
From: Andreas Schwab @ 2021-05-03 11:37 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: Michal Suchánek, linuxppc-dev
In-Reply-To: <20210503110713.751840-1-npiggin__45037.8389026568$1620040079$gmane$org@gmail.com>
Should this add a tag to the module vermagic?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* RE: [PATCH] Raise the minimum GCC version to 5.2
From: David Laight @ 2021-05-03 12:20 UTC (permalink / raw)
To: 'Arnd Bergmann', Matthew Wilcox, Linus Torvalds,
Segher Boessenkool, Joe Perches, Miguel Ojeda, Masahiro Yamada,
Albert Ou, Linux Kbuild mailing list, Greg Kroah-Hartman,
Jonathan Corbet, Linux Doc Mailing List, linux-kernel,
Palmer Dabbelt, Paul Walmsley, Catalin Marinas, Miguel Ojeda,
Paul Mackerras, linux-riscv, linuxppc-dev, Will Deacon, Linux ARM
In-Reply-To: <CAK8P3a0kV4ZfMEFh0DcMDjXqxA0yhj8a8CL-YFGV6B4pszHeGg@mail.gmail.com>
From: Arnd Bergmann
> Sent: 03 May 2021 10:25
...
> One scenario that I've seen previously is where user space and
> kernel are built together as a source based distribution (OE, buildroot,
> openwrt, ...), and the compiler is picked to match the original sources
> of the user space because that is best tested, but the same compiler
> then gets used to build the kernel as well because that is the default
> in the build environment.
If you are building programs for release to customers who might
be running then on old distributions then you need a system with
the original userspace headers and almost certainly a similar
vintage compiler.
Never mind RHEL7 we have customers running RHEL6.
(We've managed to get everyone off RHEL5.)
So the build machine is running a 10+ year old distro.
I did try to build on a newer system (only 5 years old)
but the complete fubar of memcpy() makes it impossible
to compile C programs that will run on an older libc.
And don't even mention C++, the 'character traits' is just
plain horrid - enough to make me want to remove every
reference to CString from the small amount of C++ we have.
To quote our makefile:
# C++ is fighting back.
# I'd like to be able to compile on a 'new' system and still be able to run
# the binaries on RHEL 6 (2.6.32 kernel 2011 era libraries).
# But even linking libstdc++ static still leaves
# an undefined C++ symbol that the dynamic loader barfs on.
# The static libstdc++ also references memcpy@GLIBC_2.14 - but that can be
# 'solved' by adding an extra .so that defines the symbol (and calls memmove()).
# I've also tried pulling a single .o out of libstc++.a. This might work if
# the .o is small and self contained.
#
# For now we statically link libstc++ and continue to build on an old system.
C++LDLIBS := -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
It would be nice to be able to build current kernels (for local
use) on the 'new' system - but gcc is already too old.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: David Sterba @ 2021-05-03 12:27 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Albert Ou, Arnd Bergmann, linux-kbuild, Greg Kroah-Hartman,
Jonathan Corbet, linux-doc, linux-kernel, Linus Torvalds,
Palmer Dabbelt, Paul Walmsley, Catalin Marinas, Miguel Ojeda,
Paul Mackerras, linux-riscv, linuxppc-dev, Will Deacon,
linux-arm-kernel
In-Reply-To: <20210501151538.145449-1-masahiroy@kernel.org>
On Sun, May 02, 2021 at 12:15:38AM +0900, Masahiro Yamada wrote:
> The current minimum GCC version is 4.9 except ARCH=arm64 requiring
> GCC 5.1.
>
> When we discussed last time, we agreed to raise the minimum GCC version
> to 5.1 globally. [1]
There are still a lot of comment references to old gcc releases with
workarounds or bugfixes, a quick serarch:
$ git grep -in 'gcc.*[234]\.x'
arch/alpha/include/asm/string.h:30:/* For gcc 3.x, we cannot have the inline function named "memset" because
arch/arc/include/asm/checksum.h:9: * -gcc 4.4.x broke networking. Alias analysis needed to be primed.
arch/arm/Makefile:127:# Need -Uarm for gcc < 3.x
arch/ia64/lib/memcpy_mck.S:535: * Due to lack of local tag support in gcc 2.x assembler, it is not clear which
arch/mips/include/asm/page.h:210: * also affect MIPS so we keep this one until GCC 3.x has been retired
arch/x86/include/asm/page.h:53: * remove this Voodoo magic stuff. (i.e. once gcc3.x is deprecated)
arch/x86/kvm/x86.c:5569: * This union makes it completely explicit to gcc-3.x
arch/x86/mm/pgtable.c:302: if (PREALLOCATED_PMDS == 0) /* Work around gcc-3.4.x bug */
drivers/net/ethernet/renesas/sh_eth.c:51: * that warning from W=1 builds. GCC has supported this option since 4.2.X, but
lib/xz/xz_dec_lzma2.c:494: * of the code generated by GCC 3.x decreases 10-15 %. (GCC 4.3 doesn't care,
lib/xz/xz_dec_lzma2.c:495: * and it generates 10-20 % faster code than GCC 3.x from this file anyway.)
net/core/skbuff.c:32: * The functions in this file will not compile correctly with gcc 2.4.x
This misses version-specific quirks, but the following returns 216
results and not all are problematic (eg. just referring to gcc for some
historical reason) so I'm not pasting it here.
$ git grep -in 'gcc.*[234]\.[0-9]'
...
^ permalink raw reply
* [PATCH 0/4] powerpc/security mitigation updates
From: Nicholas Piggin @ 2021-05-03 13:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
This series adds a few missing bits added to recent pseries
H_GET_CPU_CHARACTERISTICS and implements them, also removes
a restriction from powernv for some of the flushes.
This is tested mianly in qemu where I just submitted a patch
that adds support for these bits (not upstream yet).
Nicholas Piggin (4):
powerpc/pseries: Get entry and uaccess flush required bits from
H_GET_CPU_CHARACTERISTICS
powerpc/security: Add a security feature for STF barrier
powerpc/pesries: Get STF barrier requirement from
H_GET_CPU_CHARACTERISTICS
powerpc/powernv: Remove POWER9 PVR version check for entry and uaccess
flushes
arch/powerpc/include/asm/hvcall.h | 3 +++
arch/powerpc/include/asm/security_features.h | 4 ++++
arch/powerpc/kernel/security.c | 7 ++-----
arch/powerpc/platforms/powernv/setup.c | 9 ---------
arch/powerpc/platforms/pseries/setup.c | 9 +++++++++
5 files changed, 18 insertions(+), 14 deletions(-)
--
2.23.0
^ permalink raw reply
* [PATCH 1/4] powerpc/pseries: Get entry and uaccess flush required bits from H_GET_CPU_CHARACTERISTICS
From: Nicholas Piggin @ 2021-05-03 13:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20210503130243.891868-1-npiggin@gmail.com>
This allows the hypervisor / firmware to describe these workarounds to
the guest.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/hvcall.h | 2 ++
arch/powerpc/platforms/pseries/setup.c | 6 ++++++
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index 443050906018..f962b339865c 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -393,6 +393,8 @@
#define H_CPU_BEHAV_FAVOUR_SECURITY_H (1ull << 60) // IBM bit 3
#define H_CPU_BEHAV_FLUSH_COUNT_CACHE (1ull << 58) // IBM bit 5
#define H_CPU_BEHAV_FLUSH_LINK_STACK (1ull << 57) // IBM bit 6
+#define H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY (1ull << 56) // IBM bit 7
+#define H_CPU_BEHAV_NO_L1D_FLUSH_UACCESS (1ull << 55) // IBM bit 8
/* Flag values used in H_REGISTER_PROC_TBL hcall */
#define PROC_TABLE_OP_MASK 0x18
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 754e493b7c05..287f33645419 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -549,6 +549,12 @@ static void init_cpu_char_feature_flags(struct h_cpu_char_result *result)
if (!(result->behaviour & H_CPU_BEHAV_L1D_FLUSH_PR))
security_ftr_clear(SEC_FTR_L1D_FLUSH_PR);
+ if (result->behaviour & H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY)
+ security_ftr_clear(SEC_FTR_L1D_FLUSH_ENTRY);
+
+ if (result->behaviour & H_CPU_BEHAV_NO_L1D_FLUSH_UACCESS)
+ security_ftr_clear(SEC_FTR_L1D_FLUSH_UACCESS);
+
if (!(result->behaviour & H_CPU_BEHAV_BNDS_CHK_SPEC_BAR))
security_ftr_clear(SEC_FTR_BNDS_CHK_SPEC_BAR);
}
--
2.23.0
^ permalink raw reply related
* [PATCH 2/4] powerpc/security: Add a security feature for STF barrier
From: Nicholas Piggin @ 2021-05-03 13:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20210503130243.891868-1-npiggin@gmail.com>
Rather than tying this mitigation to RFI L1D flush requirement, add a
new bit for it.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/security_features.h | 4 ++++
arch/powerpc/kernel/security.c | 7 ++-----
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/security_features.h b/arch/powerpc/include/asm/security_features.h
index b774a4477d5f..792eefaf230b 100644
--- a/arch/powerpc/include/asm/security_features.h
+++ b/arch/powerpc/include/asm/security_features.h
@@ -92,6 +92,9 @@ static inline bool security_ftr_enabled(u64 feature)
// The L1-D cache should be flushed after user accesses from the kernel
#define SEC_FTR_L1D_FLUSH_UACCESS 0x0000000000008000ull
+// The STF flush should be executed on privilege state switch
+#define SEC_FTR_STF_BARRIER 0x0000000000010000ull
+
// Features enabled by default
#define SEC_FTR_DEFAULT \
(SEC_FTR_L1D_FLUSH_HV | \
@@ -99,6 +102,7 @@ static inline bool security_ftr_enabled(u64 feature)
SEC_FTR_BNDS_CHK_SPEC_BAR | \
SEC_FTR_L1D_FLUSH_ENTRY | \
SEC_FTR_L1D_FLUSH_UACCESS | \
+ SEC_FTR_STF_BARRIER | \
SEC_FTR_FAVOUR_SECURITY)
#endif /* _ASM_POWERPC_SECURITY_FEATURES_H */
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 0fdfcdd9d880..2eb257b759c6 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -300,9 +300,7 @@ static void stf_barrier_enable(bool enable)
void setup_stf_barrier(void)
{
enum stf_barrier_type type;
- bool enable, hv;
-
- hv = cpu_has_feature(CPU_FTR_HVMODE);
+ bool enable;
/* Default to fallback in case fw-features are not available */
if (cpu_has_feature(CPU_FTR_ARCH_300))
@@ -315,8 +313,7 @@ void setup_stf_barrier(void)
type = STF_BARRIER_NONE;
enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) &&
- (security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR) ||
- (security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV) && hv));
+ security_ftr_enabled(SEC_FTR_STF_BARRIER);
if (type == STF_BARRIER_FALLBACK) {
pr_info("stf-barrier: fallback barrier available\n");
--
2.23.0
^ permalink raw reply related
* [PATCH 3/4] powerpc/pesries: Get STF barrier requirement from H_GET_CPU_CHARACTERISTICS
From: Nicholas Piggin @ 2021-05-03 13:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20210503130243.891868-1-npiggin@gmail.com>
This allows the hypervisor / firmware to describe this workarounds to
the guest.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/hvcall.h | 1 +
arch/powerpc/platforms/pseries/setup.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index f962b339865c..a60ef261f63a 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -395,6 +395,7 @@
#define H_CPU_BEHAV_FLUSH_LINK_STACK (1ull << 57) // IBM bit 6
#define H_CPU_BEHAV_NO_L1D_FLUSH_ENTRY (1ull << 56) // IBM bit 7
#define H_CPU_BEHAV_NO_L1D_FLUSH_UACCESS (1ull << 55) // IBM bit 8
+#define H_CPU_BEHAV_NO_STF_BARRIER (1ull << 54) // IBM bit 9
/* Flag values used in H_REGISTER_PROC_TBL hcall */
#define PROC_TABLE_OP_MASK 0x18
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 287f33645419..631a0d57b6cd 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -555,6 +555,9 @@ static void init_cpu_char_feature_flags(struct h_cpu_char_result *result)
if (result->behaviour & H_CPU_BEHAV_NO_L1D_FLUSH_UACCESS)
security_ftr_clear(SEC_FTR_L1D_FLUSH_UACCESS);
+ if (result->behaviour & H_CPU_BEHAV_NO_STF_BARRIER)
+ security_ftr_clear(SEC_FTR_STF_BARRIER);
+
if (!(result->behaviour & H_CPU_BEHAV_BNDS_CHK_SPEC_BAR))
security_ftr_clear(SEC_FTR_BNDS_CHK_SPEC_BAR);
}
--
2.23.0
^ permalink raw reply related
* [PATCH 4/4] powerpc/powernv: Remove POWER9 PVR version check for entry and uaccess flushes
From: Nicholas Piggin @ 2021-05-03 13:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20210503130243.891868-1-npiggin@gmail.com>
These aren't necessarily POWER9 only, and it's not to say some new
vulnerability may not get discovered on other processors for which
we would like the flexibility of having the workaround enabled by
firmware.
Remove the restriction that they only apply to POWER9.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/powernv/setup.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index a8db3f153063..6ec67223f8c7 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -122,15 +122,6 @@ static void pnv_setup_security_mitigations(void)
type = L1D_FLUSH_ORI;
}
- /*
- * If we are non-Power9 bare metal, we don't need to flush on kernel
- * entry or after user access: they fix a P9 specific vulnerability.
- */
- if (!pvr_version_is(PVR_POWER9)) {
- security_ftr_clear(SEC_FTR_L1D_FLUSH_ENTRY);
- security_ftr_clear(SEC_FTR_L1D_FLUSH_UACCESS);
- }
-
enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) && \
(security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR) || \
security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV));
--
2.23.0
^ permalink raw reply related
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Miguel Ojeda @ 2021-05-03 13:10 UTC (permalink / raw)
To: David Laight
Cc: Albert Ou, Catalin Marinas, Arnd Bergmann,
Linux Kbuild mailing list, Greg Kroah-Hartman, Masahiro Yamada,
Jonathan Corbet, Linux Doc Mailing List, linux-kernel,
Matthew Wilcox, Miguel Ojeda, Will Deacon, Palmer Dabbelt,
Paul Walmsley, Joe Perches, Paul Mackerras, linux-riscv,
linuxppc-dev, Linus Torvalds, Linux ARM
In-Reply-To: <fc0c7c092f274ab8b760b3c897830347@AcuMS.aculab.com>
On Mon, May 3, 2021 at 2:20 PM David Laight <David.Laight@aculab.com> wrote:
>
> It would be nice to be able to build current kernels (for local
> use) on the 'new' system - but gcc is already too old.
I have seen such environments too... However, for the kernel in
particular, you could install a newer GCC in the 'new' machine (just
for the kernel builds) or do your kernel builds in a different machine
-- a 'new' 'new' one :)
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v5 14/16] dma-direct: Allocate memory from restricted DMA pool if available
From: Claire Chang @ 2021-05-03 14:26 UTC (permalink / raw)
To: Robin Murphy
Cc: heikki.krogerus, thomas.hellstrom, peterz, joonas.lahtinen,
dri-devel, lkml, grant.likely, paulus, Will Deacon, mingo,
Marek Szyprowski, sstabellini, Saravana Kannan, xypron.glpk,
Joerg Roedel, Rafael J . Wysocki, Christoph Hellwig,
Bartosz Golaszewski, bskeggs, linux-pci, xen-devel,
Thierry Reding, intel-gfx, matthew.auld, linux-devicetree,
Jianxiong Gao, Daniel Vetter, Konrad Rzeszutek Wilk,
maarten.lankhorst, airlied, Dan Williams, jani.nikula,
Nicolas Boichat, rodrigo.vivi, Bjorn Helgaas, boris.ostrovsky,
Andy Shevchenko, jgross, chris, nouveau, Greg KH, Randy Dunlap,
Frank Rowand, Tomasz Figa, list@263.net:IOMMU DRIVERS,
Jim Quinlan, linuxppc-dev, bauerman
In-Reply-To: <70b895c2-4a39-bbbd-a719-5c8b6b922026@arm.com>
On Fri, Apr 23, 2021 at 9:46 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2021-04-22 09:15, Claire Chang wrote:
> > The restricted DMA pool is preferred if available.
> >
> > The restricted DMA pools provide a basic level of protection against the
> > DMA overwriting buffer contents at unexpected times. However, to protect
> > against general data leakage and system memory corruption, the system
> > needs to provide a way to lock down the memory access, e.g., MPU.
> >
> > Signed-off-by: Claire Chang <tientzu@chromium.org>
> > ---
> > kernel/dma/direct.c | 35 ++++++++++++++++++++++++++---------
> > 1 file changed, 26 insertions(+), 9 deletions(-)
> >
> > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> > index 7a27f0510fcc..29523d2a9845 100644
> > --- a/kernel/dma/direct.c
> > +++ b/kernel/dma/direct.c
> > @@ -78,6 +78,10 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t size)
> > static void __dma_direct_free_pages(struct device *dev, struct page *page,
> > size_t size)
> > {
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > + if (swiotlb_free(dev, page, size))
> > + return;
> > +#endif
> > dma_free_contiguous(dev, page, size);
> > }
> >
> > @@ -92,7 +96,17 @@ static struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> >
> > gfp |= dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
> > &phys_limit);
> > - page = dma_alloc_contiguous(dev, size, gfp);
> > +
> > +#ifdef CONFIG_DMA_RESTRICTED_POOL
> > + page = swiotlb_alloc(dev, size);
> > + if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> > + __dma_direct_free_pages(dev, page, size);
> > + page = NULL;
> > + }
> > +#endif
> > +
> > + if (!page)
> > + page = dma_alloc_contiguous(dev, size, gfp);
> > if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> > dma_free_contiguous(dev, page, size);
> > page = NULL;
> > @@ -148,7 +162,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> > gfp |= __GFP_NOWARN;
> >
> > if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> > - !force_dma_unencrypted(dev)) {
> > + !force_dma_unencrypted(dev) && !is_dev_swiotlb_force(dev)) {
> > page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO);
> > if (!page)
> > return NULL;
> > @@ -161,8 +175,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> > }
> >
> > if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> > - !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> > - !dev_is_dma_coherent(dev))
> > + !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && !dev_is_dma_coherent(dev) &&
> > + !is_dev_swiotlb_force(dev))
> > return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
> >
> > /*
> > @@ -172,7 +186,9 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> > if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
> > !gfpflags_allow_blocking(gfp) &&
> > (force_dma_unencrypted(dev) ||
> > - (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && !dev_is_dma_coherent(dev))))
> > + (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> > + !dev_is_dma_coherent(dev))) &&
> > + !is_dev_swiotlb_force(dev))
> > return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
> >
> > /* we always manually zero the memory once we are done */
> > @@ -253,15 +269,15 @@ void dma_direct_free(struct device *dev, size_t size,
> > unsigned int page_order = get_order(size);
> >
> > if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> > - !force_dma_unencrypted(dev)) {
> > + !force_dma_unencrypted(dev) && !is_dev_swiotlb_force(dev)) {
> > /* cpu_addr is a struct page cookie, not a kernel address */
> > dma_free_contiguous(dev, cpu_addr, size);
> > return;
> > }
> >
> > if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> > - !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> > - !dev_is_dma_coherent(dev)) {
> > + !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && !dev_is_dma_coherent(dev) &&
> > + !is_dev_swiotlb_force(dev)) {
> > arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
> > return;
> > }
> > @@ -289,7 +305,8 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
> > void *ret;
> >
> > if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
> > - force_dma_unencrypted(dev) && !gfpflags_allow_blocking(gfp))
> > + force_dma_unencrypted(dev) && !gfpflags_allow_blocking(gfp) &&
> > + !is_dev_swiotlb_force(dev))
> > return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
>
> Wait, this seems broken for non-coherent devices - in that case we need
> to return a non-cacheable address, but we can't simply fall through into
> the remapping path below in GFP_ATOMIC context. That's why we need the
> atomic pool concept in the first place :/
Sorry for the late reply. I'm not very familiar with this. I wonder if
the memory returned here must be coherent. If yes, could we say for
this case, one must set up another device coherent pool
(shared-dma-pool) and go with dma_alloc_from_dev_coherent()[1]?
[1] https://elixir.bootlin.com/linux/v5.12/source/kernel/dma/mapping.c#L435
>
> Unless I've overlooked something, we're still using the regular
> cacheable linear map address of the dma_io_tlb_mem buffer, no?
>
> Robin.
>
> >
> > page = __dma_direct_alloc_pages(dev, size, gfp);
> >
^ permalink raw reply
* Re: [PATCH v3] powerpc/64: Option to use ELFv2 ABI for big-endian kernels
From: Michal Suchánek @ 2021-05-03 14:38 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <87eeeooxnu.fsf@igel.home>
On Mon, May 03, 2021 at 01:37:57PM +0200, Andreas Schwab wrote:
> Should this add a tag to the module vermagic?
Would the modues link even if the vermagic was not changed?
I suppose something like this might do it.
Thanks
Michal
diff --git a/arch/powerpc/include/asm/vermagic.h b/arch/powerpc/include/asm/vermagic.h
index b054a8576e5d..3fdaacd7a743 100644
--- a/arch/powerpc/include/asm/vermagic.h
+++ b/arch/powerpc/include/asm/vermagic.h
@@ -14,7 +14,14 @@
#define MODULE_ARCH_VERMAGIC_RELOCATABLE ""
#endif
+
+#ifdef CONFIG_PPC64_BUILD_BIG_ENDIAN_ELF_V2_ABI
+#define MODULE_ARCH_VERMAGIC_ELF_V2_ABI "abi-elfv2 "
+#else
+#define MODULE_ARCH_VERMAGIC_ELF_V2_ABI ""
+#endif
+
#define MODULE_ARCH_VERMAGIC \
- MODULE_ARCH_VERMAGIC_FTRACE MODULE_ARCH_VERMAGIC_RELOCATABLE
+ MODULE_ARCH_VERMAGIC_FTRACE MODULE_ARCH_VERMAGIC_RELOCATABLE MODULE_ARCH_VERMAGIC_ELF_V2_ABI
#endif /* _ASM_VERMAGIC_H */
^ permalink raw reply related
* Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels
From: Segher Boessenkool @ 2021-05-03 15:18 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <1620002801.0iaahdk9xn.astroid@bobo.none>
Hi!
On Mon, May 03, 2021 at 10:51:41AM +1000, Nicholas Piggin wrote:
> Excerpts from Segher Boessenkool's message of May 3, 2021 3:55 am:
> > On Wed, Apr 29, 2020 at 10:57:16AM +1000, Nicholas Piggin wrote:
> >> Excerpts from Segher Boessenkool's message of April 29, 2020 9:40 am:
> >> I blame toolchain for -mabi=elfv2 ! And also some blame on ABI document
> >> which is called ELF V2 ABI rather than ELF ABI V2 which would have been
> >> unambiguous.
> >
> > At least ELFv2 ABI is correct. "ELF ABI v2" is not.
> >
> >> I can go through and change all my stuff and config options to ELF_ABI_v2.
> >
> > Please don't. It is wrong.
>
> Then I'm not sure what the point of your previous mail was, what did I
> miss?
I asked if you could make it clearer to people who do not know what this
is whether they want to use it. Or that was my intention, anyhow :-/
> > Both the original PowerPC ELF ABI and the
> > ELFv2 one have versions themselves. Also, the base ELF standard has a
> > version, and is set up so there can be incompatible versions even! Of
> > course it still is version 1 to this day, but :-)
>
> The point was for people who don't know ELFv2 has a specific meaning for
> powerpc,
It does not have *any* meaning outside of Power. But people who do not
know what it is can assume the wrong things about it. It isn't a great
name because of that :-(
(It's not as bad as the MIPS ABIs -- an older one is called "new" :-) )
> then ELF ABIv2 is more explanatory about it being an abi change
> rather than base elf change, even if it's not the "correct" name.
I very much disagree. "ELF ABIv2" is completely meaningless.
> If you don't want that then good, I also prefer to just use ELFv2. I
Good :-)
> think people who change this option can easily look up the name in
> toolchain and other docs.
Yeah. As long as the defaults are good, whoever blows themselves up has
only themselves to blame :-P
Segher
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox