* Re: [PATCH v2] powerpc/64s/radix: Enable huge vmalloc mappings
From: Christophe Leroy @ 2021-05-02 17:11 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20210502110050.324953-1-npiggin@gmail.com>
Le 02/05/2021 à 13:00, 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>
> ---
> 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..ea1fa55a6897 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 CONFIG_PPC32
What then happens to PPC32 platforms that doesn't define MODULES_VADDR, for instance 4xx or booke ?
I think it should be:
#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
* [PATCH] powerpc: Don't opencode HAVE_EFFICIENT_UNALIGNED_ACCESS
From: Michal Suchanek @ 2021-05-02 17:26 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Paul Mackerras, Anton Blanchard, Michal Suchanek
There is some disconnect between commit 8a18cc0c2c36 ("powerpc: Only
disable HAVE_EFFICIENT_UNALIGNED_ACCESS on POWER7 little endian") and
commit a75c380c7129 ("powerpc: Enable DCACHE_WORD_ACCESS on ppc64le").
The first defines HAVE_EFFICIENT_UNALIGNED_ACCESS for the purpose of
enabling DCACHE_WORD_ACCESS and the second opencodes it, and differently
at that.
Fixes: a75c380c7129 ("powerpc: Enable DCACHE_WORD_ACCESS on ppc64le")
Fixes: 8a18cc0c2c36 ("powerpc: Only disable HAVE_EFFICIENT_UNALIGNED_ACCESS on POWER7 little endian")
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 75b3afbfc378..b00c37097ca2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -162,7 +162,7 @@ config PPC
select BUILDTIME_TABLE_SORT
select BUILD_ELF_V2 if PPC64 && CPU_LITTLE_ENDIAN
select CLONE_BACKWARDS
- select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
+ select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
select DMA_OPS if PPC64
select DMA_OPS_BYPASS if PPC64
select ARCH_HAS_DMA_MAP_DIRECT if PPC64 && PPC_PSERIES
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels
From: Segher Boessenkool @ 2021-05-02 17:55 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <1588121596.7zej1imag0.astroid@bobo.none>
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. 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 :-)
Segher
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Segher Boessenkool @ 2021-05-02 18:30 UTC (permalink / raw)
To: Joe Perches
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: <3943bc020f6227c8801907317fc113aa13ad4bad.camel@perches.com>
On Sat, May 01, 2021 at 07:41:53PM -0700, Joe Perches wrote:
> Why not raise the minimum gcc compiler version even higher?
The latest GCC 5 release is only three and a half years old. Do you
really want to require bleeding edge tools?
Segher
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Segher Boessenkool @ 2021-05-02 18:37 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Albert Ou, Catalin Marinas, Arnd Bergmann, linux-kbuild,
Greg Kroah-Hartman, Jonathan Corbet, linux-doc, linux-kernel,
linuxppc-dev, Will Deacon, Palmer Dabbelt, Paul Walmsley,
Miguel Ojeda, Paul Mackerras, linux-riscv, Linus Torvalds,
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]
>
> I'd like to propose GCC 5.2 to clean up arch/powerpc/Kconfig as well.
Both of these are GCC version 5. GCC 5.1 is the first release of that,
GCC 5.2 the second, etc. Everyone should always use an as new release
as practical, since many bugs will be fixed, and nothing else changed.
See <https://gcc.gnu.org/develop.html#num_scheme>.
So, this means everyone using GCC 5 should be using the GCC 5.5 release!
If there is something about 5.1 that makes it produce bad kernels on
some arch, make that arch's Makefile complain? Same with binutils etc.
Segher
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Joe Perches @ 2021-05-02 20:00 UTC (permalink / raw)
To: Segher Boessenkool
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: <20210502183030.GF10366@gate.crashing.org>
On Sun, 2021-05-02 at 13:30 -0500, Segher Boessenkool wrote:
> On Sat, May 01, 2021 at 07:41:53PM -0700, Joe Perches wrote:
> > Why not raise the minimum gcc compiler version even higher?
On Sun, 2021-05-02 at 13:37 -0500, Segher Boessenkool wrote:
> Everyone should always use an as new release as practical
[]
> The latest GCC 5 release is only three and a half years old.
You argue slightly against yourself here.
Yes, it's mostly a question of practicality vs latest.
clang requires a _very_ recent version.
gcc _could_ require a later version.
Perhaps 8 might be best as that has a __diag warning control mechanism.
gcc 8.1 is now 3 years old today.
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Segher Boessenkool @ 2021-05-02 20:32 UTC (permalink / raw)
To: Joe Perches
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: <81a926a3bdb70debe3ae2b13655ea8d249fb9991.camel@perches.com>
On Sun, May 02, 2021 at 01:00:28PM -0700, Joe Perches wrote:
> On Sun, 2021-05-02 at 13:30 -0500, Segher Boessenkool wrote:
> > On Sat, May 01, 2021 at 07:41:53PM -0700, Joe Perches wrote:
> > > Why not raise the minimum gcc compiler version even higher?
>
> On Sun, 2021-05-02 at 13:37 -0500, Segher Boessenkool wrote:
> > Everyone should always use an as new release as practical
>
> []
>
> > The latest GCC 5 release is only three and a half years old.
>
> You argue slightly against yourself here.
I don't?
> Yes, it's mostly a question of practicality vs latest.
>
> clang requires a _very_ recent version.
> gcc _could_ require a later version.
> Perhaps 8 might be best as that has a __diag warning control mechanism.
I have no idea what you mean?
> gcc 8.1 is now 3 years old today.
And there will be a new GCC 8 release very soon now!
The point is, you inconvenience users if you require a compiler version
they do not already have. Five years might be fine, but three years is
not.
Segher
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Linus Torvalds @ 2021-05-02 21:08 UTC (permalink / raw)
To: Segher Boessenkool
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: <20210502203253.GH10366@gate.crashing.org>
On Sun, May 2, 2021 at 1:38 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> The point is, you inconvenience users if you require a compiler version
> they do not already have. Five years might be fine, but three years is
> not.
So this should be our main issue - not how old a compiler is, but how
our compiler version limitations end up possibly making it harder for
users to upgrade.
Of course, one issue there is whether said users would have upgraded
regardless - if you have a very old distribution, how likely are you
to upgrade the kernel at all?
But we do very much want to encourage people to upgrade their kernels,
even if they might be running otherwise fairly old user space. If for
no other reason than that it's good for our kernel coverage testing -
the more different distributions people test a new kernel with, the
better. And some of the less common architectures have their own
issues, with distros possibly not even supporting them any more (if
they ever did - considering all the odd ad-hoc cross-compiler builds
people have had..)
This is why "our clang support requires a very recent version of
clang" is not relevant - distributions won't have old versions of
clang anyway, and even if they do, such distributions will be
gcc-based, so "build the kernel with clang" for that situation is
perhaps an exercise for some intrepid person who is willing to do odd
and unusual things, and might as well build their own clang version
too.
So I really wish people didn't get hung about some "three years ago"
or similar. It's not relevant.
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.
Linus
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Joe Perches @ 2021-05-02 21:23 UTC (permalink / raw)
To: Segher Boessenkool
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: <20210502203253.GH10366@gate.crashing.org>
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
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Ali Kaasinen @ 2021-05-02 21:05 UTC (permalink / raw)
To: Segher Boessenkool, Joe Perches
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: <20210502203253.GH10366@gate.crashing.org>
On 02/05/2021 23.32, Segher Boessenkool wrote:
> On Sun, May 02, 2021 at 01:00:28PM -0700, Joe Perches wrote:
>> On Sun, 2021-05-02 at 13:30 -0500, Segher Boessenkool wrote:
>>> On Sat, May 01, 2021 at 07:41:53PM -0700, Joe Perches wrote:
>>>> Why not raise the minimum gcc compiler version even higher?
>> On Sun, 2021-05-02 at 13:37 -0500, Segher Boessenkool wrote:
>>> Everyone should always use an as new release as practical
>> []
>>
>>> The latest GCC 5 release is only three and a half years old.
>> You argue slightly against yourself here.
> I don't?
>
>> Yes, it's mostly a question of practicality vs latest.
>>
>> clang requires a _very_ recent version.
>> gcc _could_ require a later version.
>> Perhaps 8 might be best as that has a __diag warning control mechanism.
> I have no idea what you mean?
>
>> gcc 8.1 is now 3 years old today.
> And there will be a new GCC 8 release very soon now!
>
> The point is, you inconvenience users if you require a compiler version
> they do not already have. Five years might be fine, but three years is
> not.
>
>
> Segher
Users & especially devs should upgrade then. 3 years of not updating
your compiler - if you regularly build the kernel - seems nonsensical.
Ali
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Matthew Wilcox @ 2021-05-02 22:30 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:
> 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.
^ permalink raw reply
* Re: [PATCH v2] powerpc/64s/radix: Enable huge vmalloc mappings
From: Nicholas Piggin @ 2021-05-03 0:43 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <5d2548a4-876e-ac11-87f5-b8a2e8a04232@csgroup.eu>
Excerpts from Christophe Leroy's message of May 3, 2021 3:11 am:
>
>
> Le 02/05/2021 à 13:00, 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>
>> ---
>> 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..ea1fa55a6897 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 CONFIG_PPC32
>
> What then happens to PPC32 platforms that doesn't define MODULES_VADDR, for instance 4xx or booke ?
>
> I think it should be:
>
> #ifdef MODULES_VADDR
Yes the kernel build robot agrees with you. I'll respin.
Thanks,
Nick
>
>> 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 v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels
From: Nicholas Piggin @ 2021-05-03 0:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20210502175506.GE10366@gate.crashing.org>
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?
> 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, 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.
If you don't want that then good, I also prefer to just use ELFv2. I
think people who change this option can easily look up the name in
toolchain and other docs.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Segher Boessenkool @ 2021-05-03 0:44 UTC (permalink / raw)
To: Joe Perches
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: <fcffe807353391339a03106f175ffa71377752b1.camel@perches.com>
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 :-)
Segher
^ permalink raw reply
* Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels
From: Nicholas Piggin @ 2021-05-03 0:58 UTC (permalink / raw)
To: Michal Suchánek; +Cc: linuxppc-dev
In-Reply-To: <20210502165757.GH6564@kitsune.suse.cz>
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?
>
> 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.
>
> Thanks
>
> Michal
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 6a4ad11f6349..75b3afbfc378 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -495,7 +495,7 @@ config LD_HEAD_STUB_CATCH
> If unsure, say "N".
>
> config MPROFILE_KERNEL
> - depends on PPC64 && CPU_LITTLE_ENDIAN && FUNCTION_TRACER
> + depends on PPC64 && BUILD_ELF_V2 && FUNCTION_TRACER
> def_bool $(success,$(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC) -I$(srctree)/include -D__KERNEL__)
Good idea. I can't remember if I did a grep for LITTLE_ENDIAN to check
for other such opportunities.
Thanks,
Nick
>
> config HOTPLUG_CPU
>>
>> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> Since v1:
>> - Improved the override flavour name suggested by Segher.
>> - Improved changelog wording.
>>
>>
>> arch/powerpc/Kconfig | 19 +++++++++++++++++++
>> arch/powerpc/Makefile | 15 ++++++++++-----
>> arch/powerpc/boot/Makefile | 4 ++++
>> drivers/crypto/vmx/Makefile | 8 ++++++--
>> drivers/crypto/vmx/ppc-xlate.pl | 10 ++++++----
>> 5 files changed, 45 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 924c541a9260..d9d2abc06c2c 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -147,6 +147,7 @@ config PPC
>> select ARCH_WEAK_RELEASE_ACQUIRE
>> select BINFMT_ELF
>> select BUILDTIME_TABLE_SORT
>> + select BUILD_ELF_V2 if PPC64 && CPU_LITTLE_ENDIAN
>> select CLONE_BACKWARDS
>> select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
>> select DYNAMIC_FTRACE if FUNCTION_TRACER
>> @@ -541,6 +542,24 @@ config KEXEC_FILE
>> config ARCH_HAS_KEXEC_PURGATORY
>> def_bool KEXEC_FILE
>>
>> +config BUILD_ELF_V2
>> + bool
>> +
>> +config BUILD_BIG_ENDIAN_ELF_V2
>> + bool "Build big-endian kernel using ELFv2 ABI (EXPERIMENTAL)"
>> + depends on PPC64 && CPU_BIG_ENDIAN && EXPERT
>> + default n
>> + select BUILD_ELF_V2
>> + help
>> + This builds the kernel image using the ELFv2 ABI, which has a
>> + reduced stack overhead and faster function calls. This does not
>> + affect the userspace ABIs.
>> +
>> + ELFv2 is the standard ABI for little-endian, but for big-endian
>> + this is an experimental option that is less tested (kernel and
>> + toolchain). This requires gcc 4.9 or newer 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 f310c32e88a4..e306b39d847e 100644
>> --- a/arch/powerpc/Makefile
>> +++ b/arch/powerpc/Makefile
>> @@ -92,10 +92,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_BUILD_ELF_V2
>> +cflags-y += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
>> +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
>>
>> @@ -144,7 +148,7 @@ endif
>>
>> CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no)
>> ifndef CONFIG_CC_IS_CLANG
>> -ifdef CONFIG_CPU_LITTLE_ENDIAN
>> +ifdef CONFIG_BUILD_ELF_V2
>> CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
>> AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
>> else
>> @@ -153,6 +157,7 @@ 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 c53a1b8bba8b..03942d08695d 100644
>> --- a/arch/powerpc/boot/Makefile
>> +++ b/arch/powerpc/boot/Makefile
>> @@ -41,6 +41,10 @@ endif
>>
>> BOOTCFLAGS += -isystem $(shell $(BOOTCC) -print-file-name=include)
>>
>> +ifdef CONFIG_BUILD_ELF_V2
>> +BOOTCFLAGS += $(call cc-option,-mabi=elfv2)
>> +endif
>> +
>> ifdef CONFIG_CPU_BIG_ENDIAN
>> BOOTCFLAGS += -mbig-endian
>> else
>> diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile
>> index 709670d2b553..9aea34602beb 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_BUILD_ELF_V2
>> +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..9db0937d318b 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 $abielfv2=(($flavour =~ /linux-ppc64le/) or ($flavour =~ /linux-ppc64-elfv2/))?1:0;
>> +my $dotfunctions=($abielfv2=~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 ($abielfv2);
>> $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 = ($abielfv2);
>> my $mtspr = sub {
>> my ($f,$idx,$ra) = @_;
>> if ($idx == 256 && $no_vrsave) {
>> --
>> 2.23.0
>>
>
^ permalink raw reply
* Re: [PATCH v11 1/9] powerpc/mm: Implement set_memory() routines
From: Jordan Niethe @ 2021-05-03 5:02 UTC (permalink / raw)
To: Christophe Leroy
Cc: ajd, Nicholas Piggin, cmr, Aneesh Kumar K.V, naveen.n.rao,
linuxppc-dev, Daniel Axtens
In-Reply-To: <eef1fef9-515c-3d7c-dbb7-6b93d97e35a1@csgroup.eu>
On Thu, Apr 29, 2021 at 5:32 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 29/04/2021 à 05:15, Jordan Niethe a écrit :
> > From: Russell Currey <ruscur@russell.cc>
> >
> > The set_memory_{ro/rw/nx/x}() functions are required for
> > STRICT_MODULE_RWX, and are generally useful primitives to have. This
> > implementation is designed to be generic across powerpc's many MMUs.
> > It's possible that this could be optimised to be faster for specific
> > MMUs.
> >
> > This implementation does not handle cases where the caller is attempting
> > to change the mapping of the page it is executing from, or if another
> > CPU is concurrently using the page being altered. These cases likely
> > shouldn't happen, but a more complex implementation with MMU-specific code
> > could safely handle them.
> >
> > On hash, the linear mapping is not kept in the linux pagetable, so this
> > will not change the protection if used on that range. Currently these
> > functions are not used on the linear map so just WARN for now.
> >
> > Reviewed-by: Daniel Axtens <dja@axtens.net>
> > Signed-off-by: Russell Currey <ruscur@russell.cc>
> > Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> > [jpn: - Allow set memory functions to be used without Strict RWX
> > - Hash: Disallow certain regions
> > - Have change_page_attr() take function pointers to manipulate ptes
>
> Did you look at the resulting generated code ? I find it awful.
>
> pte manipulation helpers are meant to be inlined. Here you force the compiler to outline them. This
> also means that the input and output goes through memory.
>
> And now set_memory_xx are not tiny inlined functions anymore.
>
> What is the reason you abandonned the way it was done up to now, through the use of an 'action'
> value ? With the previous approach the generated code was a lot lighter.
When I was looking at the patch again, it started to look to me like
the action values were an unneeded abstraction. But yeah doing it like
this makes the generated code much worse. I'll change back in the next
version.
>
> > - Radix: Add ptesync after set_pte_at()]
> > Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> > ---
> > v10: WARN if trying to change the hash linear map
> > v11: - Update copywrite dates
> > - Allow set memory functions to be used without Strict RWX
> > - Hash: Disallow certain regions and add comment explaining why
> > - Have change_page_attr() take function pointers to manipulate ptes
> > - Clarify change_page_attr()'s comment
> > - Radix: Add ptesync after set_pte_at()
> > ---
> > arch/powerpc/Kconfig | 1 +
> > arch/powerpc/include/asm/set_memory.h | 10 +++
> > arch/powerpc/mm/Makefile | 2 +-
> > arch/powerpc/mm/pageattr.c | 105 ++++++++++++++++++++++++++
> > 4 files changed, 117 insertions(+), 1 deletion(-)
> > create mode 100644 arch/powerpc/include/asm/set_memory.h
> > create mode 100644 arch/powerpc/mm/pageattr.c
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index cb2d44ee4e38..94c34932a74b 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -138,6 +138,7 @@ config PPC
> > select ARCH_HAS_MEMBARRIER_CALLBACKS
> > select ARCH_HAS_MEMBARRIER_SYNC_CORE
> > select ARCH_HAS_SCALED_CPUTIME if VIRT_CPU_ACCOUNTING_NATIVE && PPC_BOOK3S_64
> > + select ARCH_HAS_SET_MEMORY
> > select ARCH_HAS_STRICT_KERNEL_RWX if ((PPC_BOOK3S_64 || PPC32) && !HIBERNATION)
> > select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> > select ARCH_HAS_UACCESS_FLUSHCACHE
> > diff --git a/arch/powerpc/include/asm/set_memory.h b/arch/powerpc/include/asm/set_memory.h
> > new file mode 100644
> > index 000000000000..d1cd69b1a43a
> > --- /dev/null
> > +++ b/arch/powerpc/include/asm/set_memory.h
> > @@ -0,0 +1,10 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _ASM_POWERPC_SET_MEMORY_H
> > +#define _ASM_POWERPC_SET_MEMORY_H
> > +
> > +int set_memory_ro(unsigned long addr, int numpages);
> > +int set_memory_rw(unsigned long addr, int numpages);
> > +int set_memory_nx(unsigned long addr, int numpages);
> > +int set_memory_x(unsigned long addr, int numpages);
> > +
> > +#endif
> > diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
> > index c3df3a8501d4..9142cf1fb0d5 100644
> > --- a/arch/powerpc/mm/Makefile
> > +++ b/arch/powerpc/mm/Makefile
> > @@ -5,7 +5,7 @@
> >
> > ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
> >
> > -obj-y := fault.o mem.o pgtable.o mmap.o maccess.o \
> > +obj-y := fault.o mem.o pgtable.o mmap.o maccess.o pageattr.o \
> > init_$(BITS).o pgtable_$(BITS).o \
> > pgtable-frag.o ioremap.o ioremap_$(BITS).o \
> > init-common.o mmu_context.o drmem.o \
> > diff --git a/arch/powerpc/mm/pageattr.c b/arch/powerpc/mm/pageattr.c
> > new file mode 100644
> > index 000000000000..3b4aa72e555e
> > --- /dev/null
> > +++ b/arch/powerpc/mm/pageattr.c
> > @@ -0,0 +1,105 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +/*
> > + * MMU-generic set_memory implementation for powerpc
> > + *
> > + * Copyright 2019-2021, IBM Corporation.
> > + */
> > +
> > +#include <linux/mm.h>
> > +#include <linux/set_memory.h>
> > +
> > +#include <asm/mmu.h>
> > +#include <asm/page.h>
> > +#include <asm/pgtable.h>
> > +
> > +
> > +/*
> > + * Updates the attributes of a page in three steps:
> > + *
> > + * 1. invalidate the page table entry
> > + * 2. flush the TLB
> > + * 3. install the new entry with the updated attributes
> > + *
> > + * Invalidating the pte means there are situations where this will not work
> > + * when in theory it should.
> > + * For example:
> > + * - removing write from page whilst it is being executed
> > + * - setting a page read-only whilst it is being read by another CPU
> > + *
> > + */
> > +static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
> > +{
> > + pte_t (*fn)(pte_t) = data;
> > + pte_t pte;
> > +
> > + spin_lock(&init_mm.page_table_lock);
> > +
> > + /* invalidate the PTE so it's safe to modify */
> > + pte = ptep_get_and_clear(&init_mm, addr, ptep);
> > + flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> > +
> > + /* modify the PTE bits as desired, then apply */
> > + pte = fn(pte);
> > +
> > + set_pte_at(&init_mm, addr, ptep, pte);
> > +
> > + /* See ptesync comment in radix__set_pte_at() */
> > + if (radix_enabled())
> > + asm volatile("ptesync": : :"memory");
> > + spin_unlock(&init_mm.page_table_lock);
> > +
> > + return 0;
> > +}
> > +
> > +static int change_memory_attr(unsigned long addr, int numpages, pte_t (*fn)(pte_t))
> > +{
> > + unsigned long start = ALIGN_DOWN(addr, PAGE_SIZE);
> > + unsigned long size = numpages * PAGE_SIZE;
> > +
> > + if (!numpages)
> > + return 0;
> > +
> > +#ifdef CONFIG_PPC_BOOK3S_64
> > + /*
> > + * On hash, the linear mapping is not in the Linux page table so
> > + * apply_to_existing_page_range() will have no effect. If in the future
> > + * the set_memory_* functions are used on the linear map this will need
> > + * to be updated.
> > + */
> > + if (!radix_enabled()) {
> > + int region = get_region_id(addr);
> > +
> > + if (WARN_ON_ONCE(region != VMALLOC_REGION_ID && region != IO_REGION_ID))
> > + return -EINVAL;
> > + }
> > +#endif
> > +
> > + return apply_to_existing_page_range(&init_mm, start, size,
> > + change_page_attr, fn);
> > +}
> > +
> > +int set_memory_ro(unsigned long addr, int numpages)
> > +{
> > + return change_memory_attr(addr, numpages, pte_wrprotect);
> > +}
> > +
> > +static pte_t pte_mkdirtywrite(pte_t pte)
> > +{
> > + return pte_mkwrite(pte_mkdirty(pte));
> > +}
> > +
> > +int set_memory_rw(unsigned long addr, int numpages)
> > +{
> > + return change_memory_attr(addr, numpages, pte_mkdirtywrite);
> > +}
> > +
> > +int set_memory_nx(unsigned long addr, int numpages)
> > +{
> > + return change_memory_attr(addr, numpages, pte_exprotect);
> > +}
> > +
> > +int set_memory_x(unsigned long addr, int numpages)
> > +{
> > + return change_memory_attr(addr, numpages, pte_mkexec);
> > +}
> >
^ permalink raw reply
* Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}
From: Jordan Niethe @ 2021-05-03 5:39 UTC (permalink / raw)
To: Christophe Leroy
Cc: ajd, Nicholas Piggin, cmr, Aneesh Kumar K.V, naveen.n.rao,
linuxppc-dev, Daniel Axtens
In-Reply-To: <111c8736-fff9-ba0a-4749-f9388b32c9bf@csgroup.eu>
On Thu, Apr 29, 2021 at 3:04 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 29/04/2021 à 05:15, Jordan Niethe a écrit :
> > If MODULES_{VADDR,END} are not defined set them to VMALLOC_START and
> > VMALLOC_END respectively. This reduces the need for special cases. For
> > example, powerpc's module_alloc() was previously predicated on
> > MODULES_VADDR being defined but now is unconditionally defined.
> >
> > This will be useful reducing conditional code in other places that need
> > to allocate from the module region (i.e., kprobes).
> >
> > Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> > ---
> > v10: New to series
> > v11: - Consider more places MODULES_VADDR was being used
> > ---
> > arch/powerpc/include/asm/pgtable.h | 11 +++++++++++
> > arch/powerpc/kernel/module.c | 5 +----
> > arch/powerpc/mm/kasan/kasan_init_32.c | 10 +++++-----
> > arch/powerpc/mm/ptdump/ptdump.c | 4 ++--
> > 4 files changed, 19 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
> > index c6a676714f04..882fda779648 100644
> > --- a/arch/powerpc/include/asm/pgtable.h
> > +++ b/arch/powerpc/include/asm/pgtable.h
> > @@ -39,6 +39,17 @@ struct mm_struct;
> > #define __S110 PAGE_SHARED_X
> > #define __S111 PAGE_SHARED_X
> >
> > +#ifndef MODULES_VADDR
> > +#define MODULES_VADDR VMALLOC_START
> > +#define MODULES_END VMALLOC_END
> > +#endif
> > +
> > +#if defined(CONFIG_PPC_BOOK3S_32) && defined(CONFIG_STRICT_KERNEL_RWX)
>
> No no.
>
> TASK_SIZE > MODULES_VADDR is ALWAYS wrong, for any target, in any configuration.
>
> Why is it a problem to leave the test as a BUILD_BUG_ON() in module_alloc() ?
On ppc64s, MODULES_VADDR is __vmalloc_start (a variable) and
TASK_SIZE depends on current.
Also for nohash like 44x, MODULES_VADDR is defined based on high_memory.
If I put it back in module_alloc() and wrap it with #ifdef
CONFIG_PPC_BOOK3S_32 will that be fine?
>
> > +#if TASK_SIZE > MODULES_VADDR
> > +#error TASK_SIZE > MODULES_VADDR
> > +#endif
> > +#endif
> > +
> > #ifndef __ASSEMBLY__
> >
> > /* Keep these as a macros to avoid include dependency mess */
> > diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
> > index fab84024650c..c60c7457ff47 100644
> > --- a/arch/powerpc/kernel/module.c
> > +++ b/arch/powerpc/kernel/module.c
> > @@ -15,6 +15,7 @@
> > #include <linux/sort.h>
> > #include <asm/setup.h>
> > #include <asm/sections.h>
> > +#include <linux/mm.h>
> >
> > static LIST_HEAD(module_bug_list);
> >
> > @@ -88,7 +89,6 @@ 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)
> > {
> > @@ -102,8 +102,6 @@ void *module_alloc(unsigned long size)
> > unsigned long limit = (unsigned long)_etext - SZ_32M;
> > void *ptr = NULL;
> >
> > - BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
> > -
> > /* First try within 32M limit from _etext to avoid branch trampolines */
> > if (MODULES_VADDR < PAGE_OFFSET && MODULES_END > limit)
> > ptr = __module_alloc(size, limit, MODULES_END);
> > @@ -113,4 +111,3 @@ void *module_alloc(unsigned long size)
> >
> > return ptr;
> > }
> > -#endif
> > diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c b/arch/powerpc/mm/kasan/kasan_init_32.c
> > index cf8770b1a692..42c057366ac7 100644
> > --- a/arch/powerpc/mm/kasan/kasan_init_32.c
> > +++ b/arch/powerpc/mm/kasan/kasan_init_32.c
> > @@ -116,11 +116,11 @@ static void __init kasan_unmap_early_shadow_vmalloc(void)
> >
> > kasan_update_early_region(k_start, k_end, __pte(0));
> >
> > -#ifdef MODULES_VADDR
> > - k_start = (unsigned long)kasan_mem_to_shadow((void *)MODULES_VADDR);
> > - k_end = (unsigned long)kasan_mem_to_shadow((void *)MODULES_END);
> > - kasan_update_early_region(k_start, k_end, __pte(0));
> > -#endif
> > + if (MODULES_VADDR != VMALLOC_START && MODULES_END != VMALLOC_END) {
>
> Shouldn't it be an || ?
Yeah
>
> As soon as either MODULES_VADDR or MODULES_END differs from the vmalloc boundaries, it needs to be
> done I think.
>
> > + k_start = (unsigned long)kasan_mem_to_shadow((void *)MODULES_VADDR);
> > + k_end = (unsigned long)kasan_mem_to_shadow((void *)MODULES_END);
> > + kasan_update_early_region(k_start, k_end, __pte(0));
> > + }
> > }
> >
> > void __init kasan_mmu_init(void)
> > diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
> > index aca354fb670b..0431457f668f 100644
> > --- a/arch/powerpc/mm/ptdump/ptdump.c
> > +++ b/arch/powerpc/mm/ptdump/ptdump.c
> > @@ -73,7 +73,7 @@ struct addr_marker {
> >
> > static struct addr_marker address_markers[] = {
> > { 0, "Start of kernel VM" },
> > -#ifdef MODULES_VADDR
> > +#if defined(CONFIG_BOOK32_32) && defined(CONFIG_STRICT_KERNEL_RWX)
>
> Not valid anymore, see https://github.com/linuxppc/linux/commit/80edc68e0479 and
> https://github.com/linuxppc/linux/commit/9132a2e82adc
>
> The best would be to be able to do something like:
>
> #if MODULES_VADDR != VMALLOC_START
I tried to do it like that originally but with stuff like
#define VMALLOC_START ((((long)high_memory + VMALLOC_OFFSET) &
~(VMALLOC_OFFSET-1)))
it doesn't work.
>
> If it doesn't work, then it has to be
>
> #if defined(CONFIG_BOOK32_32) || defined(CONFIG_PPC_8xx)
Ok, thanks.
>
> > { 0, "modules start" },
> > { 0, "modules end" },
> > #endif
> > @@ -359,7 +359,7 @@ static void populate_markers(void)
> > #else
> > address_markers[i++].start_address = TASK_SIZE;
> > #endif
> > -#ifdef MODULES_VADDR
> > +#if defined(CONFIG_BOOK32_32) && defined(CONFIG_STRICT_KERNEL_RWX)
>
> Same.
>
> > address_markers[i++].start_address = MODULES_VADDR;
> > address_markers[i++].start_address = MODULES_END;
> > #endif
> >
^ permalink raw reply
* Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}
From: Christophe Leroy @ 2021-05-03 5:57 UTC (permalink / raw)
To: Jordan Niethe
Cc: ajd, Nicholas Piggin, cmr, Aneesh Kumar K.V, naveen.n.rao,
linuxppc-dev, Daniel Axtens
In-Reply-To: <CACzsE9q1QoSMVZD7yoE=3pHaRc-i14X2++ewFbBxSeZn-2u78A@mail.gmail.com>
Le 03/05/2021 à 07:39, Jordan Niethe a écrit :
> On Thu, Apr 29, 2021 at 3:04 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>>
>>
>> Le 29/04/2021 à 05:15, Jordan Niethe a écrit :
>>> If MODULES_{VADDR,END} are not defined set them to VMALLOC_START and
>>> VMALLOC_END respectively. This reduces the need for special cases. For
>>> example, powerpc's module_alloc() was previously predicated on
>>> MODULES_VADDR being defined but now is unconditionally defined.
>>>
>>> This will be useful reducing conditional code in other places that need
>>> to allocate from the module region (i.e., kprobes).
>>>
>>> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
>>> ---
>>> v10: New to series
>>> v11: - Consider more places MODULES_VADDR was being used
>>> ---
>>> arch/powerpc/include/asm/pgtable.h | 11 +++++++++++
>>> arch/powerpc/kernel/module.c | 5 +----
>>> arch/powerpc/mm/kasan/kasan_init_32.c | 10 +++++-----
>>> arch/powerpc/mm/ptdump/ptdump.c | 4 ++--
>>> 4 files changed, 19 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
>>> index c6a676714f04..882fda779648 100644
>>> --- a/arch/powerpc/include/asm/pgtable.h
>>> +++ b/arch/powerpc/include/asm/pgtable.h
>>> @@ -39,6 +39,17 @@ struct mm_struct;
>>> #define __S110 PAGE_SHARED_X
>>> #define __S111 PAGE_SHARED_X
>>>
>>> +#ifndef MODULES_VADDR
>>> +#define MODULES_VADDR VMALLOC_START
>>> +#define MODULES_END VMALLOC_END
>>> +#endif
>>> +
>>> +#if defined(CONFIG_PPC_BOOK3S_32) && defined(CONFIG_STRICT_KERNEL_RWX)
>>
>> No no.
>>
>> TASK_SIZE > MODULES_VADDR is ALWAYS wrong, for any target, in any configuration.
>>
>> Why is it a problem to leave the test as a BUILD_BUG_ON() in module_alloc() ?
> On ppc64s, MODULES_VADDR is __vmalloc_start (a variable) and
> TASK_SIZE depends on current.
> Also for nohash like 44x, MODULES_VADDR is defined based on high_memory.
> If I put it back in module_alloc() and wrap it with #ifdef
> CONFIG_PPC_BOOK3S_32 will that be fine?
Thinking about it once more, I think the best approach is the one taken by Nick in
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210502110050.324953-1-npiggin@gmail.com/
Use MODULES_VADDR/MODULES_END when it exists, use VMALLOC_START/VMALLOC_END otherwise.
I know I suggested to always define MODULES_VADDR, but maybe that's not the best solution at the end.
For kprobes, is there a way to re-use functions from modules.c in alloc_insn_page() ?
Christophe
^ permalink raw reply
* Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}
From: Jordan Niethe @ 2021-05-03 6:16 UTC (permalink / raw)
To: Christophe Leroy
Cc: ajd, Nicholas Piggin, cmr, Aneesh Kumar K.V, naveen.n.rao,
linuxppc-dev, Daniel Axtens
In-Reply-To: <6fa81d25-4313-5f15-23d9-06b314bb7d02@csgroup.eu>
On Mon, May 3, 2021 at 3:57 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 03/05/2021 à 07:39, Jordan Niethe a écrit :
> > On Thu, Apr 29, 2021 at 3:04 PM Christophe Leroy
> > <christophe.leroy@csgroup.eu> wrote:
> >>
> >>
> >>
> >> Le 29/04/2021 à 05:15, Jordan Niethe a écrit :
> >>> If MODULES_{VADDR,END} are not defined set them to VMALLOC_START and
> >>> VMALLOC_END respectively. This reduces the need for special cases. For
> >>> example, powerpc's module_alloc() was previously predicated on
> >>> MODULES_VADDR being defined but now is unconditionally defined.
> >>>
> >>> This will be useful reducing conditional code in other places that need
> >>> to allocate from the module region (i.e., kprobes).
> >>>
> >>> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> >>> ---
> >>> v10: New to series
> >>> v11: - Consider more places MODULES_VADDR was being used
> >>> ---
> >>> arch/powerpc/include/asm/pgtable.h | 11 +++++++++++
> >>> arch/powerpc/kernel/module.c | 5 +----
> >>> arch/powerpc/mm/kasan/kasan_init_32.c | 10 +++++-----
> >>> arch/powerpc/mm/ptdump/ptdump.c | 4 ++--
> >>> 4 files changed, 19 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
> >>> index c6a676714f04..882fda779648 100644
> >>> --- a/arch/powerpc/include/asm/pgtable.h
> >>> +++ b/arch/powerpc/include/asm/pgtable.h
> >>> @@ -39,6 +39,17 @@ struct mm_struct;
> >>> #define __S110 PAGE_SHARED_X
> >>> #define __S111 PAGE_SHARED_X
> >>>
> >>> +#ifndef MODULES_VADDR
> >>> +#define MODULES_VADDR VMALLOC_START
> >>> +#define MODULES_END VMALLOC_END
> >>> +#endif
> >>> +
> >>> +#if defined(CONFIG_PPC_BOOK3S_32) && defined(CONFIG_STRICT_KERNEL_RWX)
> >>
> >> No no.
> >>
> >> TASK_SIZE > MODULES_VADDR is ALWAYS wrong, for any target, in any configuration.
> >>
> >> Why is it a problem to leave the test as a BUILD_BUG_ON() in module_alloc() ?
> > On ppc64s, MODULES_VADDR is __vmalloc_start (a variable) and
> > TASK_SIZE depends on current.
> > Also for nohash like 44x, MODULES_VADDR is defined based on high_memory.
> > If I put it back in module_alloc() and wrap it with #ifdef
> > CONFIG_PPC_BOOK3S_32 will that be fine?
>
> Thinking about it once more, I think the best approach is the one taken by Nick in
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210502110050.324953-1-npiggin@gmail.com/
>
> Use MODULES_VADDR/MODULES_END when it exists, use VMALLOC_START/VMALLOC_END otherwise.
>
> I know I suggested to always define MODULES_VADDR, but maybe that's not the best solution at the end.
Sure, let's do it like that.
>
> For kprobes, is there a way to re-use functions from modules.c in alloc_insn_page() ?
Probably we can use module_alloc() then the set_memory_ functions to
get the permissions right.
Something like we had in v9:
https://lore.kernel.org/linuxppc-dev/20210316031741.1004850-3-jniethe5@gmail.com/
>
> Christophe
^ permalink raw reply
* Re: [PATCH] Raise the minimum GCC version to 5.2
From: Christophe Leroy @ 2021-05-03 6:16 UTC (permalink / raw)
To: Masahiro Yamada, linux-kernel, Linus Torvalds
Cc: Albert Ou, Catalin Marinas, Arnd Bergmann, Jonathan Corbet,
Greg Kroah-Hartman, linux-doc, Will Deacon, Palmer Dabbelt,
linux-arm-kernel, Paul Walmsley, Miguel Ojeda, Paul Mackerras,
linux-riscv, linuxppc-dev, linux-kbuild
In-Reply-To: <20210501151538.145449-1-masahiroy@kernel.org>
Le 01/05/2021 à 17:15, Masahiro Yamada a écrit :
> 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]
>
> I'd like to propose GCC 5.2 to clean up arch/powerpc/Kconfig as well.
One point I missed when I saw your patch first time, but I realised during the discussion:
Up to 4.9, GCC was numbered with 3 digits, we had 4.8.0, 4.8.1, ... 4.8.5, 4.9.0, 4.9.1, .... 4.9.4
Then starting at 5, GCC switched to a 2 digits scheme, with 5.0, 5.1, 5.2, ... 5.5
So, that is not GCC 5.1 or 5.2 that you should target, but only GCC 5.
Then it is up to the user to use the latest available version of GCC 5, which is 5.5 at the time
begin, just like the user would have selected 4.9.4 when 4.9 was the minimum GCC version.
Christophe
^ permalink raw reply
* Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}
From: Christophe Leroy @ 2021-05-03 6:22 UTC (permalink / raw)
To: Jordan Niethe
Cc: ajd, Nicholas Piggin, cmr, Aneesh Kumar K.V, naveen.n.rao,
linuxppc-dev, Daniel Axtens
In-Reply-To: <CACzsE9r-FBSo9F79cKj9c3gE7g821AhoLsRPWwd=7eFm+gMpTw@mail.gmail.com>
Le 03/05/2021 à 08:16, Jordan Niethe a écrit :
> On Mon, May 3, 2021 at 3:57 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>>
>>
>> Le 03/05/2021 à 07:39, Jordan Niethe a écrit :
>>> On Thu, Apr 29, 2021 at 3:04 PM Christophe Leroy
>>> <christophe.leroy@csgroup.eu> wrote:
>>>>
>>>>
>>>>
>>>> Le 29/04/2021 à 05:15, Jordan Niethe a écrit :
>>>>> If MODULES_{VADDR,END} are not defined set them to VMALLOC_START and
>>>>> VMALLOC_END respectively. This reduces the need for special cases. For
>>>>> example, powerpc's module_alloc() was previously predicated on
>>>>> MODULES_VADDR being defined but now is unconditionally defined.
>>>>>
>>>>> This will be useful reducing conditional code in other places that need
>>>>> to allocate from the module region (i.e., kprobes).
>>>>>
>>>>> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
>>>>> ---
>>>>> v10: New to series
>>>>> v11: - Consider more places MODULES_VADDR was being used
>>>>> ---
>>>>> arch/powerpc/include/asm/pgtable.h | 11 +++++++++++
>>>>> arch/powerpc/kernel/module.c | 5 +----
>>>>> arch/powerpc/mm/kasan/kasan_init_32.c | 10 +++++-----
>>>>> arch/powerpc/mm/ptdump/ptdump.c | 4 ++--
>>>>> 4 files changed, 19 insertions(+), 11 deletions(-)
>>>>>
>>>>> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
>>>>> index c6a676714f04..882fda779648 100644
>>>>> --- a/arch/powerpc/include/asm/pgtable.h
>>>>> +++ b/arch/powerpc/include/asm/pgtable.h
>>>>> @@ -39,6 +39,17 @@ struct mm_struct;
>>>>> #define __S110 PAGE_SHARED_X
>>>>> #define __S111 PAGE_SHARED_X
>>>>>
>>>>> +#ifndef MODULES_VADDR
>>>>> +#define MODULES_VADDR VMALLOC_START
>>>>> +#define MODULES_END VMALLOC_END
>>>>> +#endif
>>>>> +
>>>>> +#if defined(CONFIG_PPC_BOOK3S_32) && defined(CONFIG_STRICT_KERNEL_RWX)
>>>>
>>>> No no.
>>>>
>>>> TASK_SIZE > MODULES_VADDR is ALWAYS wrong, for any target, in any configuration.
>>>>
>>>> Why is it a problem to leave the test as a BUILD_BUG_ON() in module_alloc() ?
>>> On ppc64s, MODULES_VADDR is __vmalloc_start (a variable) and
>>> TASK_SIZE depends on current.
>>> Also for nohash like 44x, MODULES_VADDR is defined based on high_memory.
>>> If I put it back in module_alloc() and wrap it with #ifdef
>>> CONFIG_PPC_BOOK3S_32 will that be fine?
>>
>> Thinking about it once more, I think the best approach is the one taken by Nick in
>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210502110050.324953-1-npiggin@gmail.com/
>>
>> Use MODULES_VADDR/MODULES_END when it exists, use VMALLOC_START/VMALLOC_END otherwise.
>>
>> I know I suggested to always define MODULES_VADDR, but maybe that's not the best solution at the end.
> Sure, let's do it like that.
>>
>> For kprobes, is there a way to re-use functions from modules.c in alloc_insn_page() ?
> Probably we can use module_alloc() then the set_memory_ functions to
> get the permissions right.
> Something like we had in v9:
> https://lore.kernel.org/linuxppc-dev/20210316031741.1004850-3-jniethe5@gmail.com/
Yes, more or less, but using module_alloc() instead of vmalloc().
And module_alloc() implies EXEC, so only the set_memory_ro() will be required.
I see no point in doing any set_memory_xxx() in free_insn_page(), because as soon as you do a
vfree() the page is not mapped anymore so any access will lead to a fault.
Christophe
^ permalink raw reply
* Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}
From: Jordan Niethe @ 2021-05-03 6:26 UTC (permalink / raw)
To: Christophe Leroy
Cc: ajd, Nicholas Piggin, cmr, Aneesh Kumar K.V, naveen.n.rao,
linuxppc-dev, Daniel Axtens
In-Reply-To: <e3997b2b-cc39-e4c7-4c8b-2d004333d26a@csgroup.eu>
On Mon, May 3, 2021 at 4:22 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 03/05/2021 à 08:16, Jordan Niethe a écrit :
> > On Mon, May 3, 2021 at 3:57 PM Christophe Leroy
> > <christophe.leroy@csgroup.eu> wrote:
> >>
> >>
> >>
> >> Le 03/05/2021 à 07:39, Jordan Niethe a écrit :
> >>> On Thu, Apr 29, 2021 at 3:04 PM Christophe Leroy
> >>> <christophe.leroy@csgroup.eu> wrote:
> >>>>
> >>>>
> >>>>
> >>>> Le 29/04/2021 à 05:15, Jordan Niethe a écrit :
> >>>>> If MODULES_{VADDR,END} are not defined set them to VMALLOC_START and
> >>>>> VMALLOC_END respectively. This reduces the need for special cases. For
> >>>>> example, powerpc's module_alloc() was previously predicated on
> >>>>> MODULES_VADDR being defined but now is unconditionally defined.
> >>>>>
> >>>>> This will be useful reducing conditional code in other places that need
> >>>>> to allocate from the module region (i.e., kprobes).
> >>>>>
> >>>>> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> >>>>> ---
> >>>>> v10: New to series
> >>>>> v11: - Consider more places MODULES_VADDR was being used
> >>>>> ---
> >>>>> arch/powerpc/include/asm/pgtable.h | 11 +++++++++++
> >>>>> arch/powerpc/kernel/module.c | 5 +----
> >>>>> arch/powerpc/mm/kasan/kasan_init_32.c | 10 +++++-----
> >>>>> arch/powerpc/mm/ptdump/ptdump.c | 4 ++--
> >>>>> 4 files changed, 19 insertions(+), 11 deletions(-)
> >>>>>
> >>>>> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
> >>>>> index c6a676714f04..882fda779648 100644
> >>>>> --- a/arch/powerpc/include/asm/pgtable.h
> >>>>> +++ b/arch/powerpc/include/asm/pgtable.h
> >>>>> @@ -39,6 +39,17 @@ struct mm_struct;
> >>>>> #define __S110 PAGE_SHARED_X
> >>>>> #define __S111 PAGE_SHARED_X
> >>>>>
> >>>>> +#ifndef MODULES_VADDR
> >>>>> +#define MODULES_VADDR VMALLOC_START
> >>>>> +#define MODULES_END VMALLOC_END
> >>>>> +#endif
> >>>>> +
> >>>>> +#if defined(CONFIG_PPC_BOOK3S_32) && defined(CONFIG_STRICT_KERNEL_RWX)
> >>>>
> >>>> No no.
> >>>>
> >>>> TASK_SIZE > MODULES_VADDR is ALWAYS wrong, for any target, in any configuration.
> >>>>
> >>>> Why is it a problem to leave the test as a BUILD_BUG_ON() in module_alloc() ?
> >>> On ppc64s, MODULES_VADDR is __vmalloc_start (a variable) and
> >>> TASK_SIZE depends on current.
> >>> Also for nohash like 44x, MODULES_VADDR is defined based on high_memory.
> >>> If I put it back in module_alloc() and wrap it with #ifdef
> >>> CONFIG_PPC_BOOK3S_32 will that be fine?
> >>
> >> Thinking about it once more, I think the best approach is the one taken by Nick in
> >> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210502110050.324953-1-npiggin@gmail.com/
> >>
> >> Use MODULES_VADDR/MODULES_END when it exists, use VMALLOC_START/VMALLOC_END otherwise.
> >>
> >> I know I suggested to always define MODULES_VADDR, but maybe that's not the best solution at the end.
> > Sure, let's do it like that.
> >>
> >> For kprobes, is there a way to re-use functions from modules.c in alloc_insn_page() ?
> > Probably we can use module_alloc() then the set_memory_ functions to
> > get the permissions right.
> > Something like we had in v9:
> > https://lore.kernel.org/linuxppc-dev/20210316031741.1004850-3-jniethe5@gmail.com/
>
> Yes, more or less, but using module_alloc() instead of vmalloc().
> And module_alloc() implies EXEC, so only the set_memory_ro() will be required.
Yep.
>
> I see no point in doing any set_memory_xxx() in free_insn_page(), because as soon as you do a
> vfree() the page is not mapped anymore so any access will lead to a fault.
Yeah, I'd not realised we had VM_FLUSH_RESET_PERMS when I added that.
I agree it's pointless.
>
> Christophe
^ permalink raw reply
* Re: [PATCH v11 3/9] powerpc: Always define MODULES_{VADDR,END}
From: Christophe Leroy @ 2021-05-03 6:32 UTC (permalink / raw)
To: Jordan Niethe
Cc: ajd, Nicholas Piggin, cmr, Aneesh Kumar K.V, naveen.n.rao,
linuxppc-dev, Daniel Axtens
In-Reply-To: <CACzsE9rWVepY7v0ZFA=yG7-u5JSS=nUDDebHgVXL6Xu-BBPM+A@mail.gmail.com>
Le 03/05/2021 à 08:26, Jordan Niethe a écrit :
> On Mon, May 3, 2021 at 4:22 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>>
>>
>> Le 03/05/2021 à 08:16, Jordan Niethe a écrit :
>>> On Mon, May 3, 2021 at 3:57 PM Christophe Leroy
>>> <christophe.leroy@csgroup.eu> wrote:
>>>>
>>>>
>>>>
>>>> Le 03/05/2021 à 07:39, Jordan Niethe a écrit :
>>>>> On Thu, Apr 29, 2021 at 3:04 PM Christophe Leroy
>>>>> <christophe.leroy@csgroup.eu> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 29/04/2021 à 05:15, Jordan Niethe a écrit :
>>>>>>> If MODULES_{VADDR,END} are not defined set them to VMALLOC_START and
>>>>>>> VMALLOC_END respectively. This reduces the need for special cases. For
>>>>>>> example, powerpc's module_alloc() was previously predicated on
>>>>>>> MODULES_VADDR being defined but now is unconditionally defined.
>>>>>>>
>>>>>>> This will be useful reducing conditional code in other places that need
>>>>>>> to allocate from the module region (i.e., kprobes).
>>>>>>>
>>>>>>> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
>>>>>>> ---
>>>>>>> v10: New to series
>>>>>>> v11: - Consider more places MODULES_VADDR was being used
>>>>>>> ---
>>>>>>> arch/powerpc/include/asm/pgtable.h | 11 +++++++++++
>>>>>>> arch/powerpc/kernel/module.c | 5 +----
>>>>>>> arch/powerpc/mm/kasan/kasan_init_32.c | 10 +++++-----
>>>>>>> arch/powerpc/mm/ptdump/ptdump.c | 4 ++--
>>>>>>> 4 files changed, 19 insertions(+), 11 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
>>>>>>> index c6a676714f04..882fda779648 100644
>>>>>>> --- a/arch/powerpc/include/asm/pgtable.h
>>>>>>> +++ b/arch/powerpc/include/asm/pgtable.h
>>>>>>> @@ -39,6 +39,17 @@ struct mm_struct;
>>>>>>> #define __S110 PAGE_SHARED_X
>>>>>>> #define __S111 PAGE_SHARED_X
>>>>>>>
>>>>>>> +#ifndef MODULES_VADDR
>>>>>>> +#define MODULES_VADDR VMALLOC_START
>>>>>>> +#define MODULES_END VMALLOC_END
>>>>>>> +#endif
>>>>>>> +
>>>>>>> +#if defined(CONFIG_PPC_BOOK3S_32) && defined(CONFIG_STRICT_KERNEL_RWX)
>>>>>>
>>>>>> No no.
>>>>>>
>>>>>> TASK_SIZE > MODULES_VADDR is ALWAYS wrong, for any target, in any configuration.
>>>>>>
>>>>>> Why is it a problem to leave the test as a BUILD_BUG_ON() in module_alloc() ?
>>>>> On ppc64s, MODULES_VADDR is __vmalloc_start (a variable) and
>>>>> TASK_SIZE depends on current.
>>>>> Also for nohash like 44x, MODULES_VADDR is defined based on high_memory.
>>>>> If I put it back in module_alloc() and wrap it with #ifdef
>>>>> CONFIG_PPC_BOOK3S_32 will that be fine?
>>>>
>>>> Thinking about it once more, I think the best approach is the one taken by Nick in
>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210502110050.324953-1-npiggin@gmail.com/
>>>>
>>>> Use MODULES_VADDR/MODULES_END when it exists, use VMALLOC_START/VMALLOC_END otherwise.
>>>>
>>>> I know I suggested to always define MODULES_VADDR, but maybe that's not the best solution at the end.
>>> Sure, let's do it like that.
>>>>
>>>> For kprobes, is there a way to re-use functions from modules.c in alloc_insn_page() ?
>>> Probably we can use module_alloc() then the set_memory_ functions to
>>> get the permissions right.
>>> Something like we had in v9:
>>> https://lore.kernel.org/linuxppc-dev/20210316031741.1004850-3-jniethe5@gmail.com/
>>
>> Yes, more or less, but using module_alloc() instead of vmalloc().
>> And module_alloc() implies EXEC, so only the set_memory_ro() will be required.
> Yep.
>>
>> I see no point in doing any set_memory_xxx() in free_insn_page(), because as soon as you do a
>> vfree() the page is not mapped anymore so any access will lead to a fault.
> Yeah, I'd not realised we had VM_FLUSH_RESET_PERMS when I added that.
> I agree it's pointless.
At the end if should be quite similar to what S390 architecture does.
^ 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 7:11 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <1620003110.kzo64haq0d.astroid@bobo.none>
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.
>
> >
> > Thanks
> >
> > Michal
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 6a4ad11f6349..75b3afbfc378 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -495,7 +495,7 @@ config LD_HEAD_STUB_CATCH
> > If unsure, say "N".
> >
> > config MPROFILE_KERNEL
> > - depends on PPC64 && CPU_LITTLE_ENDIAN && FUNCTION_TRACER
> > + depends on PPC64 && BUILD_ELF_V2 && FUNCTION_TRACER
> > def_bool $(success,$(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC) -I$(srctree)/include -D__KERNEL__)
>
> Good idea. I can't remember if I did a grep for LITTLE_ENDIAN to check
> for other such opportunities.
>
> Thanks,
> Nick
>
> >
> > config HOTPLUG_CPU
> >>
> >> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
> >> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> >> ---
> >> Since v1:
> >> - Improved the override flavour name suggested by Segher.
> >> - Improved changelog wording.
> >>
> >>
> >> arch/powerpc/Kconfig | 19 +++++++++++++++++++
> >> arch/powerpc/Makefile | 15 ++++++++++-----
> >> arch/powerpc/boot/Makefile | 4 ++++
> >> drivers/crypto/vmx/Makefile | 8 ++++++--
> >> drivers/crypto/vmx/ppc-xlate.pl | 10 ++++++----
> >> 5 files changed, 45 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> >> index 924c541a9260..d9d2abc06c2c 100644
> >> --- a/arch/powerpc/Kconfig
> >> +++ b/arch/powerpc/Kconfig
> >> @@ -147,6 +147,7 @@ config PPC
> >> select ARCH_WEAK_RELEASE_ACQUIRE
> >> select BINFMT_ELF
> >> select BUILDTIME_TABLE_SORT
> >> + select BUILD_ELF_V2 if PPC64 && CPU_LITTLE_ENDIAN
> >> select CLONE_BACKWARDS
> >> select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
> >> select DYNAMIC_FTRACE if FUNCTION_TRACER
> >> @@ -541,6 +542,24 @@ config KEXEC_FILE
> >> config ARCH_HAS_KEXEC_PURGATORY
> >> def_bool KEXEC_FILE
> >>
> >> +config BUILD_ELF_V2
> >> + bool
> >> +
> >> +config BUILD_BIG_ENDIAN_ELF_V2
> >> + bool "Build big-endian kernel using ELFv2 ABI (EXPERIMENTAL)"
> >> + depends on PPC64 && CPU_BIG_ENDIAN && EXPERT
> >> + default n
> >> + select BUILD_ELF_V2
> >> + help
> >> + This builds the kernel image using the ELFv2 ABI, which has a
> >> + reduced stack overhead and faster function calls. This does not
> >> + affect the userspace ABIs.
> >> +
> >> + ELFv2 is the standard ABI for little-endian, but for big-endian
> >> + this is an experimental option that is less tested (kernel and
> >> + toolchain). This requires gcc 4.9 or newer 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 f310c32e88a4..e306b39d847e 100644
> >> --- a/arch/powerpc/Makefile
> >> +++ b/arch/powerpc/Makefile
> >> @@ -92,10 +92,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_BUILD_ELF_V2
> >> +cflags-y += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
> >> +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
> >>
> >> @@ -144,7 +148,7 @@ endif
> >>
> >> CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no)
> >> ifndef CONFIG_CC_IS_CLANG
> >> -ifdef CONFIG_CPU_LITTLE_ENDIAN
> >> +ifdef CONFIG_BUILD_ELF_V2
> >> CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
> >> AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
> >> else
> >> @@ -153,6 +157,7 @@ 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 c53a1b8bba8b..03942d08695d 100644
> >> --- a/arch/powerpc/boot/Makefile
> >> +++ b/arch/powerpc/boot/Makefile
> >> @@ -41,6 +41,10 @@ endif
> >>
> >> BOOTCFLAGS += -isystem $(shell $(BOOTCC) -print-file-name=include)
> >>
> >> +ifdef CONFIG_BUILD_ELF_V2
> >> +BOOTCFLAGS += $(call cc-option,-mabi=elfv2)
> >> +endif
> >> +
> >> ifdef CONFIG_CPU_BIG_ENDIAN
> >> BOOTCFLAGS += -mbig-endian
> >> else
> >> diff --git a/drivers/crypto/vmx/Makefile b/drivers/crypto/vmx/Makefile
> >> index 709670d2b553..9aea34602beb 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_BUILD_ELF_V2
> >> +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..9db0937d318b 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 $abielfv2=(($flavour =~ /linux-ppc64le/) or ($flavour =~ /linux-ppc64-elfv2/))?1:0;
> >> +my $dotfunctions=($abielfv2=~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 ($abielfv2);
> >> $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 = ($abielfv2);
> >> my $mtspr = sub {
> >> my ($f,$idx,$ra) = @_;
> >> if ($idx == 256 && $no_vrsave) {
> >> --
> >> 2.23.0
> >>
> >
^ permalink raw reply related
* 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
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