* Re: [PATCH 2/2] virtio-console: remove unnecessary kmemdup()
From: Xianting Tian @ 2021-08-02 8:32 UTC (permalink / raw)
To: Jiri Slaby, gregkh, amit, arnd
Cc: osandov, linuxppc-dev, linux-kernel, virtualization
In-Reply-To: <b5554967-a683-96ae-deb9-2d4980d33b41@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]
在 2021/8/2 下午3:25, Jiri Slaby 写道:
> Hi,
>
> why is this 2/2? I seem (Lore neither) to find 1/2.
You didn't receive 1/2?
[PATCH 1/2] tty: hvc: pass DMA capable memory to put_chars()
https://lkml.org/lkml/2021/8/1/8 <https://lkml.org/lkml/2021/8/1/8>
>
> On 01. 08. 21, 7:16, Xianting Tian wrote:
>> hvc framework will never pass stack memory to the put_chars() function,
>
> Am I blind or missing something?
>
> hvc_console_print(...)
> {
> char c[N_OUTBUF]
> ...
> cons_ops[index]->put_chars(vtermnos[index], c, i);
>
> The same here:
>
> hvc_poll_put_char(..., char ch)
> {
> ...
> n = hp->ops->put_chars(hp->vtermno, &ch, 1);
>
> AFAICS both of them *pass* a pointer to stack variable.
yes, I discussed the issue with Arnd before in below thread, you can
get the history, thanks
https://lkml.org/lkml/2021/7/27/494 <https://lkml.org/lkml/2021/7/27/494>
>
>> So the calling of kmemdup() is unnecessary, remove it.
>>
>> Fixes: c4baad5029 ("virtio-console: avoid DMA from stack")
>
> This patch doesn't "Fix" -- it reverts the commit. You should've CCed
> the author too.
yes, we discussed ther issue in above thread, which we CCed the author.
>
>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>> ---
>> drivers/char/virtio_console.c | 12 ++----------
>> 1 file changed, 2 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/char/virtio_console.c
>> b/drivers/char/virtio_console.c
>> index 7eaf303a7..4ed3ffb1d 100644
>> --- a/drivers/char/virtio_console.c
>> +++ b/drivers/char/virtio_console.c
>> @@ -1117,8 +1117,6 @@ static int put_chars(u32 vtermno, const char
>> *buf, int count)
>> {
>> struct port *port;
>> struct scatterlist sg[1];
>> - void *data;
>> - int ret;
>> if (unlikely(early_put_chars))
>> return early_put_chars(vtermno, buf, count);
>> @@ -1127,14 +1125,8 @@ static int put_chars(u32 vtermno, const char
>> *buf, int count)
>> if (!port)
>> return -EPIPE;
>> - data = kmemdup(buf, count, GFP_ATOMIC);
>> - if (!data)
>> - return -ENOMEM;
>> -
>> - sg_init_one(sg, data, count);
>> - ret = __send_to_port(port, sg, 1, count, data, false);
>> - kfree(data);
>> - return ret;
>> + sg_init_one(sg, buf, count);
>> + return __send_to_port(port, sg, 1, count, (void *)buf, false);
>> }
>> /*
>>
>
>
[-- Attachment #2: Type: text/html, Size: 4975 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] trace: refactor TRACE_IRQFLAGS_SUPPORT in Kconfig
From: Michael Ellerman @ 2021-08-02 2:56 UTC (permalink / raw)
To: Masahiro Yamada, Steven Rostedt, Ingo Molnar
Cc: Mark Rutland, Rich Felker, linux-sh, Peter Zijlstra,
Catalin Marinas, Linus Walleij, Viresh Kumar, linux-kernel,
James E.J. Bottomley, Max Filippov, Guo Ren, linux-csky,
H. Peter Anvin, sparclinux, linux-riscv, Vincent Chen,
Will Deacon, Ard Biesheuvel, Paul Mackerras, Anton Ivanov,
Jonas Bonn, linux-s390, Vasily Gorbik, Yoshinori Sato,
Krzysztof Kozlowski, YiFei Zhu, Richard Weinberger,
Masahiro Yamada, x86, Russell King, Ley Foon Tan,
Christian Borntraeger, Geert Uytterhoeven, linux-parisc,
Sami Tolvanen, Uwe Kleine-König, Stafford Horne,
linux-snps-arc, Jeff Dike, linux-xtensa, Albert Ou, Kees Cook,
Arnd Bergmann, Anshuman Khandual, Heiko Carstens, linux-um,
Nicholas Piggin, Stefan Kristiansson, openrisc, Borislav Petkov,
Greentime Hu, Paul Walmsley, Thomas Gleixner, linux-arm-kernel,
Andrey Konovalov, Chris Zankel, Michal Simek, Thomas Bogendoerfer,
Brian Cain, Nick Hu, Vineet Gupta, linux-mips, David S. Miller,
Frederic Weisbecker, Palmer Dabbelt, linux-hexagon,
Colin Ian King, Andrew Morton, linuxppc-dev, Helge Deller,
Mike Rapoport
In-Reply-To: <20210731052233.4703-2-masahiroy@kernel.org>
Masahiro Yamada <masahiroy@kernel.org> writes:
> Make architectures select TRACE_IRQFLAGS_SUPPORT instead of
> having many defines.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
>
> arch/Kconfig | 3 +++
> arch/arc/Kconfig | 4 +---
> arch/arm/Kconfig | 5 +----
> arch/arm64/Kconfig | 4 +---
> arch/csky/Kconfig | 4 +---
> arch/hexagon/Kconfig | 4 +---
> arch/microblaze/Kconfig | 1 +
> arch/microblaze/Kconfig.debug | 5 -----
> arch/mips/Kconfig | 1 +
> arch/mips/Kconfig.debug | 4 ----
> arch/nds32/Kconfig | 4 +---
> arch/nios2/Kconfig | 3 ---
> arch/openrisc/Kconfig | 4 +---
> arch/parisc/Kconfig | 1 +
> arch/parisc/Kconfig.debug | 3 ---
> arch/powerpc/Kconfig | 5 +----
> arch/riscv/Kconfig | 4 +---
> arch/s390/Kconfig | 1 +
> arch/s390/Kconfig.debug | 3 ---
> arch/sh/Kconfig | 1 +
> arch/sh/Kconfig.debug | 3 ---
> arch/sparc/Kconfig | 1 +
> arch/sparc/Kconfig.debug | 4 ----
> arch/um/Kconfig | 5 +----
> arch/x86/Kconfig | 1 +
> arch/x86/Kconfig.debug | 3 ---
> arch/xtensa/Kconfig | 4 +---
> 27 files changed, 21 insertions(+), 64 deletions(-)
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index d01e3401581d..76a28452c042 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -94,10 +94,6 @@ config STACKTRACE_SUPPORT
> bool
> default y
>
> -config TRACE_IRQFLAGS_SUPPORT
> - bool
> - default y
> -
> config LOCKDEP_SUPPORT
> bool
> default y
> @@ -271,6 +267,7 @@ config PPC
> select STRICT_KERNEL_RWX if STRICT_MODULE_RWX
> select SYSCTL_EXCEPTION_TRACE
> select THREAD_INFO_IN_TASK
> + select TRACE_IRQFLAGS_SUPPORT
> select VIRT_TO_BUS if !PPC64
> #
> # Please keep this list sorted alphabetically.
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
^ permalink raw reply
* [Bug 213803] G5 kernel build (v5.14-rc2) fails at linking stage - ld: arch/powerpc/mm/pgtable.o: in function `.__ptep_set_access_flags': /usr/src/linux-stable/./arch/powerpc/include/asm/book3s/64/pgtable.h:824: undefined reference to `.radix__ptep_set_access_flags'
From: bugzilla-daemon @ 2021-08-02 22:07 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-213803-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=213803
--- Comment #1 from Erhard F. (erhard_f@mailbox.org) ---
Still a problem in v5.14-rc4.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH 3/3] isystem: delete global -isystem compile option
From: Segher Boessenkool @ 2021-08-02 21:42 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: linux-arch, Will Deacon, Catalin Marinas, masahiroy, linux-kernel,
Paul Mackerras, akpm, linuxppc-dev, linux-arm-kernel
In-Reply-To: <YQhVyOdQKUnvz1n5@localhost.localdomain>
On Mon, Aug 02, 2021 at 11:30:00PM +0300, Alexey Dobriyan wrote:
> On Mon, Aug 02, 2021 at 11:47:47AM -0500, Segher Boessenkool wrote:
> > The kernel *cannot* make up its own types for this. It has to use the
> > types it is required to use (by C, by the ABIs, etc.) So why
> > reimplement this?
>
> Yes, it can. gcc headers have stuff like this:
>
> #define __PTRDIFF_TYPE__ long int
> #define __SIZE_TYPE__ long unsigned int
>
> If gcc can defined standard types, kernel can too.
The kernel *has to* use those exact same types. So why on earth do you
feel you should reimplement this?
> > > noreturn, alignas newest C standard
> > > are next.
> >
> > What is wrong with <stdalign.h> and <stdnoreturn.h>?
>
> These two are actually quite nice.
>
> Have you seen <stddef.h>? Loads of macrology crap.
> Kernel can ship nicer one.
It is a pretty tame file. And it works correctly for *all* targets,
including all Linux targets. Why reimplement this? No, it takes
virtually no resources to compile this. And you do not have to maintain
it *at all*, the compiler will take care of it. It is standard.
> > > They are userspace headers in the sense they are external to the project
> > > just like userspace programs are external to the kernel.
> >
> > So you are going to rewrite all of the rest of GCC inside the kernel
> > project as well?
>
> What an argument. "the rest of GCC" is already there except for stdarg.h.
???
That is there as well. But you want to remove it.
"The rest of GCC" is everything in cc1 (the compiler binary), in libgcc
(not that the kernel wants that either on most targets, although it is
required), etc. A few GB of binary goodness.
> > > Kernel chose to be self-contained.
> >
> > That is largely historical, imo. Nowadays this is less necessary.
>
> I kind of agree as in kernel should use int8_t and stuff because they
> are standard.
s8 is a much nicer name, heh. But it could
#define s8 int8_t
certainly.
What I meant was the kernel wanted to avoid standard headers because
those traditionally have been a bit problematic. But decades have gone
by, and nowadays the kernel's own headers are at least as bad.
> Also, -isystem removal disables <float.h> and <stdatomic.h> which is
> desireable.
Why? Do you think #include <float.h> will ever make it past code
review? Do you need to throw up extra barriers so people will have a
harder time changing that policy, if ever they think that a good idea?
> > > It will be used for intrinsics where necessary.
> >
> > Like, everywhere.
>
> No, where necessary. Patch demostrates there are only a few places which
> want -isystem back.
Yes, where necessary, that is what I said. So, potentially everywhere.
An arch can decide to use some builtin in a generic header, for example.
Your patch makes for more work in the future, that is the best it does.
Segher
^ permalink raw reply
* Re: [PATCH 3/3] isystem: delete global -isystem compile option
From: Nathan Chancellor @ 2021-08-02 20:38 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: linux-arch, Catalin Marinas, masahiroy, linuxppc-dev,
linux-kernel, Paul Mackerras, akpm, Will Deacon, linux-arm-kernel
In-Reply-To: <YQhWQkbN+pe354RW@localhost.localdomain>
On 8/2/2021 1:32 PM, Alexey Dobriyan wrote:
> On Mon, Aug 02, 2021 at 11:18:32AM -0700, Nathan Chancellor wrote:
>> On Sun, Aug 01, 2021 at 11:13:36PM +0300, Alexey Dobriyan wrote:
>>> In theory, it enables "leakage" of userspace headers into kernel which
>>> may present licensing problem.
>>>
>>> In practice, only stdarg.h was used, stdbool.h is trivial and SIMD
>>> intrinsics are contained to a few architectures and aren't global
>>> problem.
>>>
>>> In general, kernel is very self contained code and -isystem removal
>>> will further isolate it from Ring Threeland influence.
>>>
>>> nds32 keeps -isystem globally due to intrisics used in entrenched header.
>>>
>>> -isystem is selectively reenabled for some files.
>>>
>>> Not compile tested on hexagon.
>>
>> With this series on top of v5.14-rc4 and a tangential patch to fix
>> another issue, ARCH=hexagon defconfig and allmodconfig show no issues.
>>
>> Tested-by: Nathan Chancellor <nathan@kernel> # build (hexagon)
>
> Oh wow, small miracle. Thank you!
>
> Where can I find a cross-compiler? This link doesn't seem to have one
> https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/
Hexagon only builds with LLVM now because of the bump to require gcc
4.9: https://lore.kernel.org/r/20210623141854.GA32155@lst.de/
Brian Cain has a link in that thread to an LLVM toolchain that works
well for defconfig (allmodconfig requires LLVM 13/14 from git).
Otherwise, https://apt.llvm.org or LLVM from your package manager should
be sufficient for the same targets.
$ make -skj"$(nproc)" ARCH=hexagon CROSS_COMPILE=hexagon-linux-musl-
LLVM=1 LLVM_IAS=1 defconfig all
should work fine as long as the bin folder for whatever toolchain you
download is in your PATH.
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH 3/3] isystem: delete global -isystem compile option
From: Alexey Dobriyan @ 2021-08-02 20:32 UTC (permalink / raw)
To: Nathan Chancellor
Cc: linux-arch, Catalin Marinas, masahiroy, linuxppc-dev,
linux-kernel, Paul Mackerras, akpm, Will Deacon, linux-arm-kernel
In-Reply-To: <YQg2+C4Z98BMFucg@archlinux-ax161>
On Mon, Aug 02, 2021 at 11:18:32AM -0700, Nathan Chancellor wrote:
> On Sun, Aug 01, 2021 at 11:13:36PM +0300, Alexey Dobriyan wrote:
> > In theory, it enables "leakage" of userspace headers into kernel which
> > may present licensing problem.
> >
> > In practice, only stdarg.h was used, stdbool.h is trivial and SIMD
> > intrinsics are contained to a few architectures and aren't global
> > problem.
> >
> > In general, kernel is very self contained code and -isystem removal
> > will further isolate it from Ring Threeland influence.
> >
> > nds32 keeps -isystem globally due to intrisics used in entrenched header.
> >
> > -isystem is selectively reenabled for some files.
> >
> > Not compile tested on hexagon.
>
> With this series on top of v5.14-rc4 and a tangential patch to fix
> another issue, ARCH=hexagon defconfig and allmodconfig show no issues.
>
> Tested-by: Nathan Chancellor <nathan@kernel> # build (hexagon)
Oh wow, small miracle. Thank you!
Where can I find a cross-compiler? This link doesn't seem to have one
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/
^ permalink raw reply
* Re: [PATCH 3/3] isystem: delete global -isystem compile option
From: Alexey Dobriyan @ 2021-08-02 20:30 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linux-arch, Will Deacon, Catalin Marinas, masahiroy, linux-kernel,
Paul Mackerras, akpm, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20210802164747.GN1583@gate.crashing.org>
On Mon, Aug 02, 2021 at 11:47:47AM -0500, Segher Boessenkool wrote:
> On Mon, Aug 02, 2021 at 09:42:45AM +0300, Alexey Dobriyan wrote:
> > On Sun, Aug 01, 2021 at 04:32:47PM -0500, Segher Boessenkool wrote:
> > > On Sun, Aug 01, 2021 at 11:13:36PM +0300, Alexey Dobriyan wrote:
> > > > In theory, it enables "leakage" of userspace headers into kernel which
> > > > may present licensing problem.
> > >
> > > > -NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
> > > > +NOSTDINC_FLAGS += -nostdinc
> > >
> > > This is removing the compiler's own include files. These are required
> > > for all kinds of basic features, and required to be compliant to the C
> > > standard at all.
> >
> > No they are not required.
>
> This is false, they *are* required, whenever you want to use these
> features. If you do not include the required headers you get undefined
> behaviour.
>
> > Kernel uses its own bool, uintptr_t and
> > static_assert, memset(), CHAR_BIT.
>
> Yes, and it occasionally gets it wrong. Great fun. See c46bbf5d2def
> for the latest episode in this saga. (Yes I know this is uapi so maybe
> not the best example here, but it isn't like the kernel gets such things
> wrong so often these days ;-) )
>
> The kernel *cannot* make up its own types for this. It has to use the
> types it is required to use (by C, by the ABIs, etc.) So why
> reimplement this?
Yes, it can. gcc headers have stuff like this:
#define __PTRDIFF_TYPE__ long int
#define __SIZE_TYPE__ long unsigned int
If gcc can defined standard types, kernel can too.
> > noreturn, alignas newest C standard
> > are next.
>
> What is wrong with <stdalign.h> and <stdnoreturn.h>?
These two are actually quite nice.
Have you seen <stddef.h>? Loads of macrology crap.
Kernel can ship nicer one.
> > This version changelog didn't mention but kernel would use
> > -ffreestanding too if not other problems with the flag.
>
> It is still true for freestanding C implementations, you just get a
> severely reduced standard library,
>
> > > These are not "userspace headers", that is what
> > > -nostdinc takes care of already.
> >
> > They are userspace headers in the sense they are external to the project
> > just like userspace programs are external to the kernel.
>
> So you are going to rewrite all of the rest of GCC inside the kernel
> project as well?
What an argument. "the rest of GCC" is already there except for stdarg.h.
> > > In the case of GCC all these headers are GPL-with-runtime-exception, so
> > > claiming this can cause licensing problems is fearmongering.
> >
> > I agree licensing problem doesn't really exist.
> > It would take gcc drop-in replacement with authors insane enough to not
> > license standard headers properly.
>
> There does still not exist a drop-in replacement for GCC, not if you
> look closely and/or rely on details (like the kernel does). Some of the
> differences are hidden by "linux/compiler-*.h", but hardly all.
>
> > > I strongly advise against doing this.
> >
> > Kernel chose to be self-contained.
>
> That is largely historical, imo. Nowadays this is less necessary.
I kind of agree as in kernel should use int8_t and stuff because they
are standard.
Also, -isystem removal disables <float.h> and <stdatomic.h> which is
desireable.
> Also, the kernel chose to *do* use the compiler include files. It is
> you who wants to abolish that here.
>
> > -isystem removal makes sense then.
>
> -nostdinc -isystem $(shell $(CC) -print-file-name=include) makes sense
> for that: you do indeed not want the userspace headers. Maiming the
> compiler (by removing some of its functional parts, namely, its generic
> headers) does not make sense.
>
> > It will be used for intrinsics where necessary.
>
> Like, everywhere.
No, where necessary. Patch demostrates there are only a few places which
want -isystem back.
^ permalink raw reply
* Re: [PATCH 3/3] isystem: delete global -isystem compile option
From: Nathan Chancellor @ 2021-08-02 18:18 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: linux-arch, Catalin Marinas, masahiroy, linuxppc-dev,
linux-kernel, Paul Mackerras, akpm, Will Deacon, linux-arm-kernel
In-Reply-To: <20210801201336.2224111-3-adobriyan@gmail.com>
On Sun, Aug 01, 2021 at 11:13:36PM +0300, Alexey Dobriyan wrote:
> In theory, it enables "leakage" of userspace headers into kernel which
> may present licensing problem.
>
> In practice, only stdarg.h was used, stdbool.h is trivial and SIMD
> intrinsics are contained to a few architectures and aren't global
> problem.
>
> In general, kernel is very self contained code and -isystem removal
> will further isolate it from Ring Threeland influence.
>
> nds32 keeps -isystem globally due to intrisics used in entrenched header.
>
> -isystem is selectively reenabled for some files.
>
> Not compile tested on hexagon.
With this series on top of v5.14-rc4 and a tangential patch to fix
another issue, ARCH=hexagon defconfig and allmodconfig show no issues.
Tested-by: Nathan Chancellor <nathan@kernel> # build (hexagon)
> Compile tested on:
>
> alpha-allmodconfig alpha-allnoconfig alpha-defconfig arm64-allmodconfig
> arm64-allnoconfig arm64-defconfig arm-am200epdkit arm-aspeed_g4
> arm-aspeed_g5 arm-assabet arm-at91_dt arm-axm55xx arm-badge4 arm-bcm2835
> arm-cerfcube arm-clps711x arm-cm_x300 arm-cns3420vb arm-colibri_pxa270
> arm-colibri_pxa300 arm-collie arm-corgi arm-davinci_all arm-dove
> arm-ep93xx arm-eseries_pxa arm-exynos arm-ezx arm-footbridge arm-gemini
> arm-h3600 arm-h5000 arm-hackkit arm-hisi arm-imote2 arm-imx_v4_v5
> arm-imx_v6_v7 arm-integrator arm-iop32x arm-ixp4xx arm-jornada720
> arm-keystone arm-lart arm-lpc18xx arm-lpc32xx arm-lpd270 arm-lubbock
> arm-magician arm-mainstone arm-milbeaut_m10v arm-mini2440 arm-mmp2
> arm-moxart arm-mps2 arm-multi_v4t arm-multi_v5 arm-multi_v7 arm-mv78xx0
> arm-mvebu_v5 arm-mvebu_v7 arm-mxs arm-neponset arm-netwinder arm-nhk8815
> arm-omap1 arm-omap2plus arm-orion5x arm-oxnas_v6 arm-palmz72 arm-pcm027
> arm-pleb arm-pxa arm-pxa168 arm-pxa255-idp arm-pxa3xx arm-pxa910
> arm-qcom arm-realview arm-rpc arm-s3c2410 arm-s3c6400 arm-s5pv210
> arm-sama5 arm-shannon arm-shmobile arm-simpad arm-socfpga arm-spear13xx
> arm-spear3xx arm-spear6xx arm-spitz arm-stm32 arm-sunxi arm-tct_hammer
> arm-tegra arm-trizeps4 arm-u8500 arm-versatile arm-vexpress arm-vf610m4
> arm-viper arm-vt8500_v6_v7 arm-xcep arm-zeus csky-allmodconfig
> csky-allnoconfig csky-defconfig h8300-edosk2674 h8300-h8300h-sim
> h8300-h8s-sim i386-allmodconfig i386-allnoconfig i386-defconfig
> ia64-allmodconfig ia64-allnoconfig ia64-bigsur ia64-generic ia64-gensparse
> ia64-tiger ia64-zx1 m68k-amcore m68k-amiga m68k-apollo m68k-atari
> m68k-bvme6000 m68k-hp300 m68k-m5208evb m68k-m5249evb m68k-m5272c3
> m68k-m5275evb m68k-m5307c3 m68k-m5407c3 m68k-m5475evb m68k-mac
> m68k-multi m68k-mvme147 m68k-mvme16x m68k-q40 m68k-stmark2 m68k-sun3
> m68k-sun3x microblaze-allmodconfig microblaze-allnoconfig microblaze-mmu
> mips-ar7 mips-ath25 mips-ath79 mips-bcm47xx mips-bcm63xx mips-bigsur
> mips-bmips_be mips-bmips_stb mips-capcella mips-cavium_octeon mips-ci20
> mips-cobalt mips-cu1000-neo mips-cu1830-neo mips-db1xxx mips-decstation
> mips-decstation_64 mips-decstation_r4k mips-e55 mips-fuloong2e
> mips-gcw0 mips-generic mips-gpr mips-ip22 mips-ip27 mips-ip28 mips-ip32
> mips-jazz mips-jmr3927 mips-lemote2f mips-loongson1b mips-loongson1c
> mips-loongson2k mips-loongson3 mips-malta mips-maltaaprp mips-malta_kvm
> mips-malta_qemu_32r6 mips-maltasmvp mips-maltasmvp_eva mips-maltaup
> mips-maltaup_xpa mips-mpc30x mips-mtx1 mips-nlm_xlp mips-nlm_xlr
> mips-omega2p mips-pic32mzda mips-pistachio mips-qi_lb60 mips-rb532
> mips-rbtx49xx mips-rm200 mips-rs90 mips-rt305x mips-sb1250_swarm
> mips-tb0219 mips-tb0226 mips-tb0287 mips-vocore2 mips-workpad mips-xway
> nds32-allmodconfig nds32-allnoconfig nds32-defconfig nios2-10m50
> nios2-3c120 nios2-allmodconfig nios2-allnoconfig openrisc-allmodconfig
> openrisc-allnoconfig openrisc-or1klitex openrisc-or1ksim
> openrisc-simple_smp parisc-allnoconfig parisc-generic-32bit
> parisc-generic-64bit powerpc-acadia powerpc-adder875 powerpc-akebono
> powerpc-amigaone powerpc-arches powerpc-asp8347 powerpc-bamboo
> powerpc-bluestone powerpc-canyonlands powerpc-cell powerpc-chrp32
> powerpc-cm5200 powerpc-currituck powerpc-ebony powerpc-eiger
> powerpc-ep8248e powerpc-ep88xc powerpc-fsp2 powerpc-g5 powerpc-gamecube
> powerpc-ge_imp3a powerpc-holly powerpc-icon powerpc-iss476-smp
> powerpc-katmai powerpc-kilauea powerpc-klondike powerpc-kmeter1
> powerpc-ksi8560 powerpc-linkstation powerpc-lite5200b powerpc-makalu
> powerpc-maple powerpc-mgcoge powerpc-microwatt powerpc-motionpro
> powerpc-mpc512x powerpc-mpc5200 powerpc-mpc7448_hpc2 powerpc-mpc8272_ads
> powerpc-mpc8313_rdb powerpc-mpc8315_rdb powerpc-mpc832x_mds
> powerpc-mpc832x_rdb powerpc-mpc834x_itx powerpc-mpc834x_itxgp
> powerpc-mpc834x_mds powerpc-mpc836x_mds powerpc-mpc836x_rdk
> powerpc-mpc837x_mds powerpc-mpc837x_rdb powerpc-mpc83xx
> powerpc-mpc8540_ads powerpc-mpc8560_ads powerpc-mpc85xx_cds
> powerpc-mpc866_ads powerpc-mpc885_ads powerpc-mvme5100 powerpc-obs600
> powerpc-pasemi powerpc-pcm030 powerpc-pmac32 powerpc-powernv
> powerpc-ppa8548 powerpc-ppc40x powerpc-ppc44x powerpc-ppc64
> powerpc-ppc64e powerpc-ppc6xx powerpc-pq2fads powerpc-ps3
> powerpc-pseries powerpc-rainier powerpc-redwood powerpc-sam440ep
> powerpc-sbc8548 powerpc-sequoia powerpc-skiroot powerpc-socrates
> powerpc-storcenter powerpc-stx_gp3 powerpc-taishan powerpc-tqm5200
> powerpc-tqm8540 powerpc-tqm8541 powerpc-tqm8548 powerpc-tqm8555
> powerpc-tqm8560 powerpc-tqm8xx powerpc-walnut powerpc-warp powerpc-wii
> powerpc-xes_mpc85xx riscv-allmodconfig riscv-allnoconfig riscv-nommu_k210
> riscv-nommu_k210_sdcard riscv-nommu_virt riscv-rv32 s390-allmodconfig
> s390-allnoconfig s390-debug s390-zfcpdump sh-ap325rxa sh-apsh4a3a
> sh-apsh4ad0a sh-dreamcast sh-ecovec24 sh-ecovec24-romimage sh-edosk7705
> sh-edosk7760 sh-espt sh-hp6xx sh-j2 sh-kfr2r09 sh-kfr2r09-romimage
> sh-landisk sh-lboxre2 sh-magicpanelr2 sh-microdev sh-migor sh-polaris
> sh-r7780mp sh-r7785rp sh-rsk7201 sh-rsk7203 sh-rsk7264 sh-rsk7269
> sh-rts7751r2d1 sh-rts7751r2dplus sh-sdk7780 sh-sdk7786 sh-se7206 sh-se7343
> sh-se7619 sh-se7705 sh-se7712 sh-se7721 sh-se7722 sh-se7724 sh-se7750
> sh-se7751 sh-se7780 sh-secureedge5410 sh-sh03 sh-sh2007 sh-sh7710voipgw
> sh-sh7724_generic sh-sh7757lcr sh-sh7763rdp sh-sh7770_generic sh-sh7785lcr
> sh-sh7785lcr_32bit sh-shmin sh-shx3 sh-titan sh-ul2 sh-urquell
> sparc-allmodconfig sparc-allnoconfig sparc-sparc32 sparc-sparc64
> um-i386-allmodconfig um-i386-allnoconfig um-i386-defconfig
> um-x86_64-allmodconfig um-x86_64-allnoconfig x86_64-allmodconfig
> x86_64-allnoconfig x86_64-defconfig xtensa-allmodconfig xtensa-allnoconfig
> xtensa-audio_kc705 xtensa-cadence_csp xtensa-common xtensa-generic_kc705
> xtensa-iss xtensa-nommu_kc705 xtensa-smp_lx200 xtensa-virt
> xtensa-xip_kc705
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ---
> Makefile | 2 +-
> arch/arm64/lib/Makefile | 2 ++
> arch/nds32/Makefile | 2 ++
> arch/powerpc/lib/Makefile | 2 ++
> crypto/Makefile | 2 ++
> lib/raid6/Makefile | 4 ++++
> 6 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 6b555f64df06..b59053ec457a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -979,7 +979,7 @@ KBUILD_CFLAGS += -falign-functions=64
> endif
>
> # arch Makefile may override CC so keep this after arch Makefile is included
> -NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
> +NOSTDINC_FLAGS += -nostdinc
>
> # warn about C99 declaration after statement
> KBUILD_CFLAGS += -Wdeclaration-after-statement
> diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
> index 6dd56a49790a..dcad998f12d7 100644
> --- a/arch/arm64/lib/Makefile
> +++ b/arch/arm64/lib/Makefile
> @@ -9,6 +9,8 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON), y)
> obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
> CFLAGS_REMOVE_xor-neon.o += -mgeneral-regs-only
> CFLAGS_xor-neon.o += -ffreestanding
> +# Enable <arm_neon.h>
> +CFLAGS_xor-neon.o += -isystem $(shell $(CC) -print-file-name=include)
> endif
>
> lib-$(CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE) += uaccess_flushcache.o
> diff --git a/arch/nds32/Makefile b/arch/nds32/Makefile
> index ccdca7142020..c17fc3a755c3 100644
> --- a/arch/nds32/Makefile
> +++ b/arch/nds32/Makefile
> @@ -9,6 +9,8 @@ endif
> # Avoid generating FPU instructions
> arch-y += -mno-ext-fpu-sp -mno-ext-fpu-dp -mfloat-abi=soft
>
> +# Enable <nds32_intrinsic.h>
> +KBUILD_CFLAGS += -isystem $(shell $(CC) -print-file-name=include)
> KBUILD_CFLAGS += $(call cc-option, -mno-sched-prolog-epilog)
> KBUILD_CFLAGS += -mcmodel=large
>
> diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
> index 99a7c9132422..9e5d0f413b71 100644
> --- a/arch/powerpc/lib/Makefile
> +++ b/arch/powerpc/lib/Makefile
> @@ -65,5 +65,7 @@ obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
>
> obj-$(CONFIG_ALTIVEC) += xor_vmx.o xor_vmx_glue.o
> CFLAGS_xor_vmx.o += -maltivec $(call cc-option,-mabi=altivec)
> +# Enable <altivec.h>
> +CFLAGS_xor_vmx.o += -isystem $(shell $(CC) -print-file-name=include)
>
> obj-$(CONFIG_PPC64) += $(obj64-y)
> diff --git a/crypto/Makefile b/crypto/Makefile
> index 10526d4559b8..75ad9b040506 100644
> --- a/crypto/Makefile
> +++ b/crypto/Makefile
> @@ -117,6 +117,8 @@ aegis128-cflags-$(CONFIG_CC_IS_GCC) += -ffixed-q16 -ffixed-q17 -ffixed-q18 \
> -ffixed-q28 -ffixed-q29 -ffixed-q30 \
> -ffixed-q31
> CFLAGS_aegis128-neon-inner.o += $(aegis128-cflags-y)
> +# Enable <arm_neon.h>
> +CFLAGS_aegis128-neon-inner.o += -isystem $(shell $(CC) -print-file-name=include)
> CFLAGS_REMOVE_aegis128-neon-inner.o += -mgeneral-regs-only
> aegis128-$(CONFIG_CRYPTO_AEGIS128_SIMD) += aegis128-neon.o aegis128-neon-inner.o
> endif
> diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
> index c770570bfe4f..45e17619422b 100644
> --- a/lib/raid6/Makefile
> +++ b/lib/raid6/Makefile
> @@ -14,6 +14,8 @@ hostprogs += mktables
>
> ifeq ($(CONFIG_ALTIVEC),y)
> altivec_flags := -maltivec $(call cc-option,-mabi=altivec)
> +# Enable <altivec.h>
> +altivec_flags += -isystem $(shell $(CC) -print-file-name=include)
>
> ifdef CONFIG_CC_IS_CLANG
> # clang ppc port does not yet support -maltivec when -msoft-float is
> @@ -34,6 +36,8 @@ endif
> # ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)
> ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> NEON_FLAGS := -ffreestanding
> +# Enable <arm_neon.h>
> +NEON_FLAGS += -isystem $(shell $(CC) -print-file-name=include)
> ifeq ($(ARCH),arm)
> NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
> endif
> --
> 2.31.1
>
^ permalink raw reply
* Re: Possible regression by ab037dd87a2f (powerpc/vdso: Switch VDSO to generic C implementation.)
From: Segher Boessenkool @ 2021-08-02 18:07 UTC (permalink / raw)
To: Michael Ellerman
Cc: parkerderek86, pmenzel, laboger, xaionaro, Paul Murphy, paulus,
murphyp, linuxppc-dev
In-Reply-To: <87czqwl67h.fsf@mpe.ellerman.id.au>
On Mon, Aug 02, 2021 at 04:18:58PM +1000, Michael Ellerman wrote:
> > Go up to this point has only used the vdso function __kernel_clock_gettime; it
> > is the only entry point which would need to explicitly avoid R30 for
> > Go's sake.
>
> I thought about limiting the workaround to just that code, but it seemed
> silly and likely to come back to bite us. Once the compilers decides to
> spill a non-volatile there are plenty of other ones to choose from.
It can be cheaper to spill N..31 consecutively, using stmw for example.
For 64-bit Power implementations it doesn't currently make any
difference. Since none of this will be inlined it doesn't have any real
impact.
(This also happens with -m32 -fpic, which always sets GPR30 as fixed, it
is the offset table register. With those flags -ffixed-r30 doesn't do
anything btw (r30 already *is* a fixed function register), and this will
not work with a Go that clobbers r30. But this is academic :-) )
Segher
^ permalink raw reply
* Re: Debian SID kernel doesn't boot on PowerBook 3400c
From: Stan Johnson @ 2021-08-02 17:32 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Debian PowerPC, linuxppc-dev, Finn Thain
In-Reply-To: <fbd08736-9738-35cf-3b47-b5c9c455c552@csgroup.eu>
[-- Attachment #1: Type: text/plain, Size: 5574 bytes --]
On 8/2/21 8:41 AM, Christophe Leroy wrote:
>
>
> Le 31/07/2021 à 20:24, Stan Johnson a écrit :
>> Hi Christophe,
>>
>> On 7/31/21 9:58 AM, Christophe Leroy wrote:
>>> Stan Johnson <userm57@yahoo.com> a écrit :
>>>
>>>> Hello,
>>>>
>>>> The current Debian SID kernel will not boot on a PowerBook 3400c
>>>> running
>>>> the latest version of Debian SID. If booted using the BootX extension,
>>>> the kernel hangs immediately:
>>>>
>>>> "Welcome to Linux, kernel 5.10.0-8-powerpc"
>>>>
>>>> If booted from Mac OS, the Mac OS screen hangs.
>>>>
>>>> Booting also hangs if the "No video driver" option is selected in
>>>> BootX,
>>>> "No video driver" causes "video=ofonly" to be passed to the kernel.
>>>>
>>>> This is the current command line that I'm using in BootX:
>>>> root=/dev/sda13 video=chips65550:vmode:14,cmode:16
>>>>
>>>> Kernel v5.9 works as expected.
>>>>
>>>> The config file I'm using is attached.
>>>>
>>>> Here are the results of a git bisect, marking v5.9 as "good" and the
>>>> most current kernel as "bad":
>>>>
>>>> $ cd linux
>>>> $ git remote update
>>>> $ git bisect reset
>>>> $ git bisect start
>>>> $ git bisect bad
>>>> $ git bisect good v5.9
>>>>
>>>> Note: "bad" -> hangs at boot; "good" -> boots to login prompt
>>>>
>>>> 1) 5.11.0-rc5-pmac-00034-g684da7628d9 (bad)
>>>> 2) 5.10.0-rc3-pmac-00383-gbb9dd3ce617 (good)
>>>> 3) 5.10.0-pmac-06637-g2911ed9f47b (good)
>>>> Note: I had to disable SMP to build this kernel.
>>>> 4) 5.10.0-pmac-10584-g9805529ec54 (good)
>>>> Note: I had to disable SMP to build this kernel.
>>>> 5) 5.10.0-pmac-12577-g8552d28e140 (bad)
>>>> 6) 5.10.0-pmac-11576-g8a5be36b930 (bad)
>>>> 7) 5.10.0-pmac-11044-gbe695ee29e8 (good)
>>>> Note: I had to disable SMP to build this kernel.
>>>> 8) 5.10.0-rc2-pmac-00288-g59d512e4374 (bad)
>>>> 9) 5.10.0-rc2-pmac-00155-gc3d35ddd1ec (good)
>>>> 10) 5.10.0-rc2-pmac-00221-g7049b288ea8 (good)
>>>> 11) 5.10.0-rc2-pmac-00254-g4b74a35fc7e (bad)
>>>> 12) 5.10.0-rc2-pmac-00237-ged22bb8d39f (good)
>>>> 13) 5.10.0-rc2-pmac-00245-g87b57ea7e10 (good)
>>>> 14) 5.10.0-rc2-pmac-00249-gf10881a46f8 (bad)
>>>> 15) 5.10.0-rc2-pmac-00247-gf8a4b277c3c (good)
>>>> 16) 5.10.0-rc2-pmac-00248-gdb972a3787d (bad)
>>>>
>>>> db972a3787d12b1ce9ba7a31ec376d8a79e04c47 is the first bad commit
>>>
>>> Not sure this is really the root of the problem.
>>>
>>> Can you try again without CONFIG_VMAP_STACK ?
>>>
>>> Thanks
>>> Christophe
>>> ...
>>
>>
>> With CONFIG_VMAP_STACK=y, 5.11.0-rc5-pmac-00034-g684da7628d9 hangs at
>> boot on the PB 3400c.
>>
>> Without CONFIG_VMAP_STACK, 5.11.0-rc5-pmac-00034-g684da7628d9 boots as
>> expected.
>>
>> I didn't re-build the Debian SID kernel, though I confirmed that the
>> Debian config file for 5.10.0-8-powerpc includes CONFIG_VMAP_STACK=y.
>> It's not clear whether removing CONFIG_VMAP_STACK would be appropriate
>> for other powerpc systems.
>>
>> Please let me know why removing CONFIG_VMAP_STACK fixed the problem on
>> the PB 3400c. Should CONFIG_HAVE_ARCH_VMAP_STACK also be removed?
>>
>
> When CONFIG_HAVE_ARCH_VMAP_STACK is selected by the architecture,
> CONFIG_VMAP_STACK is selected by default.
>
> The point is that your config has CONFIG_ADB_PMU.
>
> A bug with VMAP stack was detected during 5.9 release cycle for
> platforms selecting CONFIG_ADB_PMU. Because fixing the bug was an heavy
> change, we prefered at that time to disable VMAP stack, so VMAP stack
> was deselected for CONFIG_ADB_PMU by commit
> 4a133eb351ccc275683ad49305d0b04dde903733.
>
> Then as a second step, the proper fix was implemented and then VMAP
> stack was enabled again by the commit you bisected.
>
> Taking into account that the problem disappears for you when you
> manually deselect VMAP stacks, it means the problem is not the fix
> itself, but the fact that VMAP stacks are now enable by default.
>
> We need to understand why VMAP stack doesn't work on your platform, more
> than that why it doesn't boot at all with VMAP stack.
>
> Could you send me the dmesg output of your system when it properly boots ?
>
> Did you check with kernel 5.13 ?
>
> Thanks
> Christophe
>
Christophe,
Thanks for your response. It looks like I never tested v5.13 (I was
originally just reporting that the default Debian SID kernel,
5.10.0-8-powerpc, hangs at boot on the PB 3400c).
So I rebuilt the stock v5.13 from kernel.org using Finn's
dot-config-powermac-5.13, which got changed slightly at compilation (see
dot-config-v5.13-pmac, attached). It has CONFIG_VMAP_STACK and
CONFIG_ADB_PMU set, and it booted, but there were multiple memory
errors. So it looks like the hang-at-boot problem was fixed sometime
after v5.11, but there are now memory errors (similar to Wallstreet).
With CONFIG_VMAP_STACK not set (CONFIG_ADB_PMU is still set), the
.config file turns into the attached dot-config-v5.13-pmac_NO_VMAP. And
there were still memory errors (dmesg output attached).
The memory errors may be a completely unrelated issue, since they occur
regardless of the CONFIG_VMAP_STACK setting.
To help rule out a hardware issue, I confirmed that memory errors don't
occur with v5.8.2 (dmesg output attached).
A useful git bisect might be possible if CONFIG_VMAP_STACK is disabled
for each build. I would need to determine where the memory errors
started (v5.9, v5.10, v5.11, or v5.12). There is the complication that
(at least) several v5.10 kernels won't compile if SMP is set, so I might
need to disable that everywhere as well, assuming the SMP fix didn't
cause the memory errors.
-Stan
[-- Attachment #2: dot-config-v5.13-pmac.xz --]
[-- Type: application/octet-stream, Size: 17980 bytes --]
[-- Attachment #3: dot-config-v5.13-pmac_NO_VMAP.xz --]
[-- Type: application/octet-stream, Size: 17976 bytes --]
[-- Attachment #4: dmesg_5.13_VMAP.txt.xz --]
[-- Type: application/octet-stream, Size: 8700 bytes --]
[-- Attachment #5: dmesg_5.13_NO_VMAP.txt.xz --]
[-- Type: application/octet-stream, Size: 6656 bytes --]
[-- Attachment #6: dmesg_5.8.2.txt.xz --]
[-- Type: application/octet-stream, Size: 6096 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] isystem: delete global -isystem compile option
From: Segher Boessenkool @ 2021-08-02 16:47 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: linux-arch, Will Deacon, Catalin Marinas, masahiroy, linux-kernel,
Paul Mackerras, akpm, linuxppc-dev, linux-arm-kernel
In-Reply-To: <YQeT5QRXc3CzK9nL@localhost.localdomain>
On Mon, Aug 02, 2021 at 09:42:45AM +0300, Alexey Dobriyan wrote:
> On Sun, Aug 01, 2021 at 04:32:47PM -0500, Segher Boessenkool wrote:
> > On Sun, Aug 01, 2021 at 11:13:36PM +0300, Alexey Dobriyan wrote:
> > > In theory, it enables "leakage" of userspace headers into kernel which
> > > may present licensing problem.
> >
> > > -NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
> > > +NOSTDINC_FLAGS += -nostdinc
> >
> > This is removing the compiler's own include files. These are required
> > for all kinds of basic features, and required to be compliant to the C
> > standard at all.
>
> No they are not required.
This is false, they *are* required, whenever you want to use these
features. If you do not include the required headers you get undefined
behaviour.
> Kernel uses its own bool, uintptr_t and
> static_assert, memset(), CHAR_BIT.
Yes, and it occasionally gets it wrong. Great fun. See c46bbf5d2def
for the latest episode in this saga. (Yes I know this is uapi so maybe
not the best example here, but it isn't like the kernel gets such things
wrong so often these days ;-) )
The kernel *cannot* make up its own types for this. It has to use the
types it is required to use (by C, by the ABIs, etc.) So why
reimplement this?
> noreturn, alignas newest C standard
> are next.
What is wrong with <stdalign.h> and <stdnoreturn.h>?
> This version changelog didn't mention but kernel would use
> -ffreestanding too if not other problems with the flag.
It is still true for freestanding C implementations, you just get a
severely reduced standard library,
> > These are not "userspace headers", that is what
> > -nostdinc takes care of already.
>
> They are userspace headers in the sense they are external to the project
> just like userspace programs are external to the kernel.
So you are going to rewrite all of the rest of GCC inside the kernel
project as well?
> > In the case of GCC all these headers are GPL-with-runtime-exception, so
> > claiming this can cause licensing problems is fearmongering.
>
> I agree licensing problem doesn't really exist.
> It would take gcc drop-in replacement with authors insane enough to not
> license standard headers properly.
There does still not exist a drop-in replacement for GCC, not if you
look closely and/or rely on details (like the kernel does). Some of the
differences are hidden by "linux/compiler-*.h", but hardly all.
> > I strongly advise against doing this.
>
> Kernel chose to be self-contained.
That is largely historical, imo. Nowadays this is less necessary.
Also, the kernel chose to *do* use the compiler include files. It is
you who wants to abolish that here.
> -isystem removal makes sense then.
-nostdinc -isystem $(shell $(CC) -print-file-name=include) makes sense
for that: you do indeed not want the userspace headers. Maiming the
compiler (by removing some of its functional parts, namely, its generic
headers) does not make sense.
> It will be used for intrinsics where necessary.
Like, everywhere.
Segher
^ permalink raw reply
* Re: [PATCH v3 31/41] powerpc/32: Dismantle EXC_XFER_STD/LITE/TEMPLATE
From: LEROY Christophe @ 2021-08-02 15:19 UTC (permalink / raw)
To: Finn Thain
Cc: Stan Johnson, linux-kernel, Nick Piggin, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1d601b7c-1e39-e372-39a5-e1e98e56e2a5@linux-m68k.org>
Le 01/08/2021 à 03:21, Finn Thain a écrit :
> On Sat, 31 Jul 2021, Christophe Leroy wrote:
>
>>>
>>> Stan Johnson contacted me about a regression in mainline that he
>>> observed on his G3 Powerbooks. Using 'git bisect' we determined that
>>> this patch was the cause of the regression, i.e. commit 4c0104a83fc3
>>> ("powerpc/32: Dismantle EXC_XFER_STD/LITE/TEMPLATE").
>>>
>>> When testing 4c0104a83fc and all subsequent builds, various user
>>> processes were liable to segfault. Here is the console log that Stan
>>> provided:
>>
>> Hi, i will be able to look at that more in details next week, however I
>> have a few preliminary qurstions.
>>
>> Can you reliabily reproduce the problem with the said commit, and can
>> you reliabily run without problem with the parent commit ?
>
> Yes and yes. (I already asked Stan to establish those things before I
> contacted the list.)
I think I found the problem with that commit. Can you retry with the
following change:
diff --git a/arch/powerpc/kernel/head_book3s_32.S
b/arch/powerpc/kernel/head_book3s_32.S
index 0a3d7d4a9ec4..a294103a91a1 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -299,7 +299,7 @@ ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_HPTE_TABLE)
EXCEPTION_PROLOG_1
EXCEPTION_PROLOG_2 0x300 DataAccess handle_dar_dsisr=1
prepare_transfer_to_handler
- lwz r5, _DSISR(r11)
+ lwz r5, _DSISR(r1)
andis. r0, r5, DSISR_DABRMATCH@h
bne- 1f
bl do_page_fault
---
Thanks
Christophe
^ permalink raw reply related
* Re: Debian SID kernel doesn't boot on PowerBook 3400c
From: Christophe Leroy @ 2021-08-02 14:41 UTC (permalink / raw)
To: Stan Johnson; +Cc: Debian PowerPC, linuxppc-dev, Finn Thain
In-Reply-To: <cd7c931c-a578-a2ff-0632-7767a0e90bb9@yahoo.com>
Le 31/07/2021 à 20:24, Stan Johnson a écrit :
> Hi Christophe,
>
> On 7/31/21 9:58 AM, Christophe Leroy wrote:
>> Stan Johnson <userm57@yahoo.com> a écrit :
>>
>>> Hello,
>>>
>>> The current Debian SID kernel will not boot on a PowerBook 3400c running
>>> the latest version of Debian SID. If booted using the BootX extension,
>>> the kernel hangs immediately:
>>>
>>> "Welcome to Linux, kernel 5.10.0-8-powerpc"
>>>
>>> If booted from Mac OS, the Mac OS screen hangs.
>>>
>>> Booting also hangs if the "No video driver" option is selected in BootX,
>>> "No video driver" causes "video=ofonly" to be passed to the kernel.
>>>
>>> This is the current command line that I'm using in BootX:
>>> root=/dev/sda13 video=chips65550:vmode:14,cmode:16
>>>
>>> Kernel v5.9 works as expected.
>>>
>>> The config file I'm using is attached.
>>>
>>> Here are the results of a git bisect, marking v5.9 as "good" and the
>>> most current kernel as "bad":
>>>
>>> $ cd linux
>>> $ git remote update
>>> $ git bisect reset
>>> $ git bisect start
>>> $ git bisect bad
>>> $ git bisect good v5.9
>>>
>>> Note: "bad" -> hangs at boot; "good" -> boots to login prompt
>>>
>>> 1) 5.11.0-rc5-pmac-00034-g684da7628d9 (bad)
>>> 2) 5.10.0-rc3-pmac-00383-gbb9dd3ce617 (good)
>>> 3) 5.10.0-pmac-06637-g2911ed9f47b (good)
>>> Note: I had to disable SMP to build this kernel.
>>> 4) 5.10.0-pmac-10584-g9805529ec54 (good)
>>> Note: I had to disable SMP to build this kernel.
>>> 5) 5.10.0-pmac-12577-g8552d28e140 (bad)
>>> 6) 5.10.0-pmac-11576-g8a5be36b930 (bad)
>>> 7) 5.10.0-pmac-11044-gbe695ee29e8 (good)
>>> Note: I had to disable SMP to build this kernel.
>>> 8) 5.10.0-rc2-pmac-00288-g59d512e4374 (bad)
>>> 9) 5.10.0-rc2-pmac-00155-gc3d35ddd1ec (good)
>>> 10) 5.10.0-rc2-pmac-00221-g7049b288ea8 (good)
>>> 11) 5.10.0-rc2-pmac-00254-g4b74a35fc7e (bad)
>>> 12) 5.10.0-rc2-pmac-00237-ged22bb8d39f (good)
>>> 13) 5.10.0-rc2-pmac-00245-g87b57ea7e10 (good)
>>> 14) 5.10.0-rc2-pmac-00249-gf10881a46f8 (bad)
>>> 15) 5.10.0-rc2-pmac-00247-gf8a4b277c3c (good)
>>> 16) 5.10.0-rc2-pmac-00248-gdb972a3787d (bad)
>>>
>>> db972a3787d12b1ce9ba7a31ec376d8a79e04c47 is the first bad commit
>>
>> Not sure this is really the root of the problem.
>>
>> Can you try again without CONFIG_VMAP_STACK ?
>>
>> Thanks
>> Christophe
>> ...
>
>
> With CONFIG_VMAP_STACK=y, 5.11.0-rc5-pmac-00034-g684da7628d9 hangs at
> boot on the PB 3400c.
>
> Without CONFIG_VMAP_STACK, 5.11.0-rc5-pmac-00034-g684da7628d9 boots as
> expected.
>
> I didn't re-build the Debian SID kernel, though I confirmed that the
> Debian config file for 5.10.0-8-powerpc includes CONFIG_VMAP_STACK=y.
> It's not clear whether removing CONFIG_VMAP_STACK would be appropriate
> for other powerpc systems.
>
> Please let me know why removing CONFIG_VMAP_STACK fixed the problem on
> the PB 3400c. Should CONFIG_HAVE_ARCH_VMAP_STACK also be removed?
>
When CONFIG_HAVE_ARCH_VMAP_STACK is selected by the architecture, CONFIG_VMAP_STACK is selected by
default.
The point is that your config has CONFIG_ADB_PMU.
A bug with VMAP stack was detected during 5.9 release cycle for platforms selecting CONFIG_ADB_PMU.
Because fixing the bug was an heavy change, we prefered at that time to disable VMAP stack, so VMAP
stack was deselected for CONFIG_ADB_PMU by commit 4a133eb351ccc275683ad49305d0b04dde903733.
Then as a second step, the proper fix was implemented and then VMAP stack was enabled again by the
commit you bisected.
Taking into account that the problem disappears for you when you manually deselect VMAP stacks, it
means the problem is not the fix itself, but the fact that VMAP stacks are now enable by default.
We need to understand why VMAP stack doesn't work on your platform, more than that why it doesn't
boot at all with VMAP stack.
Could you send me the dmesg output of your system when it properly boots ?
Did you check with kernel 5.13 ?
Thanks
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc/xive: Do not skip CPU-less nodes when creating the IPIs
From: Cédric Le Goater @ 2021-08-02 12:59 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
Cc: Laurent Vivier, Srikar Dronamraju, Geetika Moolchandani, stable,
David Gibson, Kairui Song
In-Reply-To: <87a6m0l5by.fsf@mpe.ellerman.id.au>
On 8/2/21 8:37 AM, Michael Ellerman wrote:
> Cédric Le Goater <clg@kaod.org> writes:
>> On PowerVM, CPU-less nodes can be populated with hot-plugged CPUs at
>> runtime. Today, the IPI is not created for such nodes, and hot-plugged
>> CPUs use a bogus IPI, which leads to soft lockups.
>>
>> We could create the node IPI on demand but it is a bit complex because
>> this code would be called under bringup_up() and some IRQ locking is
>> being done. The simplest solution is to create the IPIs for all nodes
>> at startup.
>>
>> Fixes: 7dcc37b3eff9 ("powerpc/xive: Map one IPI interrupt per node")
>> Cc: stable@vger.kernel.org # v5.13
>> Reported-by: Geetika Moolchandani <Geetika.Moolchandani1@ibm.com>
>> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>>
>> This patch breaks old versions of irqbalance (<= v1.4). Possible nodes
>> are collected from /sys/devices/system/node/ but CPU-less nodes are
>> not listed there. When interrupts are scanned, the link representing
>> the node structure is NULL and segfault occurs.
>
> Breaking userspace is usually frowned upon, even if it is irqbalance.
>
> If CPU-less nodes appeared in /sys/devices/system/node would that fix
> it? Could we do that or is that not possible for other reasons?
>
>> Version 1.7 seems immune.
>
> Which was released in August 2020.
>
> Looks like some distros still ship 1.6, I take it you're not sure if
> that is broken or not.
I did a bisect on irqbalance and the "bad" commit was introduced between
version 1.7 and version 1.8 :
commit 31dea01f3a47 ("Also fetch node info for non-PCI devices")
https://github.com/Irqbalance/irqbalance/commit/31dea01f3a47aa6374560638486879e5129f9c94
which was backported on RHEL 8 in RPM irqbalance-1.4.0-6.el8.
Any distro using irqbalance <= 1.7 without the patch above is fine.
Since irqbalance handled cleanly irqs referencing offline nodes before
this patch, I am inclined to think that the irqbalance fix is incomplete.
Unfortunately, the commit log lacks some context on the non-PCI devices.
Thanks,
C.
^ permalink raw reply
* Re: Possible regression by ab037dd87a2f (powerpc/vdso: Switch VDSO to generic C implementation.)
From: Benjamin Herrenschmidt @ 2021-08-02 12:48 UTC (permalink / raw)
To: Michael Ellerman, Paul Murphy, pmenzel
Cc: parkerderek86, laboger, xaionaro, paulus, murphyp, linuxppc-dev
In-Reply-To: <87czqwl67h.fsf@mpe.ellerman.id.au>
On Mon, 2021-08-02 at 16:18 +1000, Michael Ellerman wrote:
>
> But to be fair the ABI of the VDSO has always been a little fishy,
>
> because the entry points pretend to be a transparent wrapper around
>
> system calls, but then in a case like this are not.
This is somewhat debatable :-) If your perspective is from an
application, whether your wrapper is glibc, the vdso or *** knows what
else, you can't make assumptions about the state of the registers on a
signal hitting somewhere in your call chain other than what's
guanranteed by the ABI overall (ie, TLS etc...).
Nowhere was it written that a VDSO call behaved strictly like an sc
instruction :-)
>
> > Go up to this point has only used the vdso function __kernel_clock_gettime; it
> > is the only entry point which would need to explicitly avoid R30 for
> > Go's sake.
>
>
> I thought about limiting the workaround to just that code, but it seemed
> silly and likely to come back to bite us. Once the compilers decides to
> spill a non-volatile there are plenty of other ones to choose from.
Yeah fine graining this is a waste of time, I agree. Just stick with
fixing r30 for the whole vdso, it won't actually hurt, just make sure
this is somewhat documented as to why we do it (I don't remember what
you patch does off hand, I assume at least your git commit has all the
data, a comment near the offending line in the Makefile might be good
too).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has()
From: Christophe Leroy @ 2021-08-02 12:42 UTC (permalink / raw)
To: Tom Lendacky, linux-kernel, x86, linuxppc-dev, linux-s390, iommu,
kvm, linux-efi, platform-driver-x86, linux-graphics-maintainer,
amd-gfx, dri-devel, kexec, linux-fsdevel
Cc: Sathyanarayanan Kuppuswamy, Andi Kleen, Tianyu Lan,
Thomas Zimmermann, Baoquan He, Peter Zijlstra, Will Deacon,
Joerg Roedel, Dave Hansen, Maarten Lankhorst, Maxime Ripard,
David Airlie, Andy Lutomirski, Ingo Molnar, Borislav Petkov,
Daniel Vetter, Brijesh Singh, Thomas Gleixner, Dave Young
In-Reply-To: <029791b24c6412f9427cfe6ec598156c64395964.1627424774.git.thomas.lendacky@amd.com>
Le 28/07/2021 à 00:26, Tom Lendacky a écrit :
> Replace occurrences of mem_encrypt_active() with calls to prot_guest_has()
> with the PATTR_MEM_ENCRYPT attribute.
What about
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210730114231.23445-1-will@kernel.org/ ?
Christophe
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Will Deacon <will@kernel.org>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Baoquan He <bhe@redhat.com>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/x86/kernel/head64.c | 4 ++--
> arch/x86/mm/ioremap.c | 4 ++--
> arch/x86/mm/mem_encrypt.c | 5 ++---
> arch/x86/mm/pat/set_memory.c | 3 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +++-
> drivers/gpu/drm/drm_cache.c | 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 6 +++---
> drivers/iommu/amd/iommu.c | 3 ++-
> drivers/iommu/amd/iommu_v2.c | 3 ++-
> drivers/iommu/iommu.c | 3 ++-
> fs/proc/vmcore.c | 6 +++---
> kernel/dma/swiotlb.c | 4 ++--
> 13 files changed, 29 insertions(+), 24 deletions(-)
>
> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> index de01903c3735..cafed6456d45 100644
> --- a/arch/x86/kernel/head64.c
> +++ b/arch/x86/kernel/head64.c
> @@ -19,7 +19,7 @@
> #include <linux/start_kernel.h>
> #include <linux/io.h>
> #include <linux/memblock.h>
> -#include <linux/mem_encrypt.h>
> +#include <linux/protected_guest.h>
> #include <linux/pgtable.h>
>
> #include <asm/processor.h>
> @@ -285,7 +285,7 @@ unsigned long __head __startup_64(unsigned long physaddr,
> * there is no need to zero it after changing the memory encryption
> * attribute.
> */
> - if (mem_encrypt_active()) {
> + if (prot_guest_has(PATTR_MEM_ENCRYPT)) {
> vaddr = (unsigned long)__start_bss_decrypted;
> vaddr_end = (unsigned long)__end_bss_decrypted;
> for (; vaddr < vaddr_end; vaddr += PMD_SIZE) {
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 0f2d5ace5986..5e1c1f5cbbe8 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -693,7 +693,7 @@ static bool __init early_memremap_is_setup_data(resource_size_t phys_addr,
> bool arch_memremap_can_ram_remap(resource_size_t phys_addr, unsigned long size,
> unsigned long flags)
> {
> - if (!mem_encrypt_active())
> + if (!prot_guest_has(PATTR_MEM_ENCRYPT))
> return true;
>
> if (flags & MEMREMAP_ENC)
> @@ -723,7 +723,7 @@ pgprot_t __init early_memremap_pgprot_adjust(resource_size_t phys_addr,
> {
> bool encrypted_prot;
>
> - if (!mem_encrypt_active())
> + if (!prot_guest_has(PATTR_MEM_ENCRYPT))
> return prot;
>
> encrypted_prot = true;
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 451de8e84fce..0f1533dbe81c 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -364,8 +364,7 @@ int __init early_set_memory_encrypted(unsigned long vaddr, unsigned long size)
> /*
> * SME and SEV are very similar but they are not the same, so there are
> * times that the kernel will need to distinguish between SME and SEV. The
> - * sme_active() and sev_active() functions are used for this. When a
> - * distinction isn't needed, the mem_encrypt_active() function can be used.
> + * sme_active() and sev_active() functions are used for this.
> *
> * The trampoline code is a good example for this requirement. Before
> * paging is activated, SME will access all memory as decrypted, but SEV
> @@ -451,7 +450,7 @@ void __init mem_encrypt_free_decrypted_mem(void)
> * The unused memory range was mapped decrypted, change the encryption
> * attribute from decrypted to encrypted before freeing it.
> */
> - if (mem_encrypt_active()) {
> + if (sme_me_mask) {
> r = set_memory_encrypted(vaddr, npages);
> if (r) {
> pr_warn("failed to free unused decrypted pages\n");
> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index ad8a5c586a35..6925f2bb4be1 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -18,6 +18,7 @@
> #include <linux/libnvdimm.h>
> #include <linux/vmstat.h>
> #include <linux/kernel.h>
> +#include <linux/protected_guest.h>
>
> #include <asm/e820/api.h>
> #include <asm/processor.h>
> @@ -1986,7 +1987,7 @@ static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
> int ret;
>
> /* Nothing to do if memory encryption is not active */
> - if (!mem_encrypt_active())
> + if (!prot_guest_has(PATTR_MEM_ENCRYPT))
> return 0;
>
> /* Should not be working on unaligned addresses */
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index abb928894eac..8407224717df 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -38,6 +38,7 @@
> #include <drm/drm_probe_helper.h>
> #include <linux/mmu_notifier.h>
> #include <linux/suspend.h>
> +#include <linux/protected_guest.h>
>
> #include "amdgpu.h"
> #include "amdgpu_irq.h"
> @@ -1239,7 +1240,8 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> * however, SME requires an indirect IOMMU mapping because the encryption
> * bit is beyond the DMA mask of the chip.
> */
> - if (mem_encrypt_active() && ((flags & AMD_ASIC_MASK) == CHIP_RAVEN)) {
> + if (prot_guest_has(PATTR_MEM_ENCRYPT) &&
> + ((flags & AMD_ASIC_MASK) == CHIP_RAVEN)) {
> dev_info(&pdev->dev,
> "SME is not compatible with RAVEN\n");
> return -ENOTSUPP;
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index 546599f19a93..4d01d44012fd 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -31,7 +31,7 @@
> #include <linux/dma-buf-map.h>
> #include <linux/export.h>
> #include <linux/highmem.h>
> -#include <linux/mem_encrypt.h>
> +#include <linux/protected_guest.h>
> #include <xen/xen.h>
>
> #include <drm/drm_cache.h>
> @@ -204,7 +204,7 @@ bool drm_need_swiotlb(int dma_bits)
> * Enforce dma_alloc_coherent when memory encryption is active as well
> * for the same reasons as for Xen paravirtual hosts.
> */
> - if (mem_encrypt_active())
> + if (prot_guest_has(PATTR_MEM_ENCRYPT))
> return true;
>
> for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling)
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index dde8b35bb950..06ec95a650ba 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -29,7 +29,7 @@
> #include <linux/dma-mapping.h>
> #include <linux/module.h>
> #include <linux/pci.h>
> -#include <linux/mem_encrypt.h>
> +#include <linux/protected_guest.h>
>
> #include <drm/ttm/ttm_range_manager.h>
> #include <drm/drm_aperture.h>
> @@ -634,7 +634,7 @@ static int vmw_dma_select_mode(struct vmw_private *dev_priv)
> [vmw_dma_map_bind] = "Giving up DMA mappings early."};
>
> /* TTM currently doesn't fully support SEV encryption. */
> - if (mem_encrypt_active())
> + if (prot_guest_has(PATTR_MEM_ENCRYPT))
> return -EINVAL;
>
> if (vmw_force_coherent)
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> index 3d08f5700bdb..0c70573d3dce 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
> @@ -28,7 +28,7 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/slab.h>
> -#include <linux/mem_encrypt.h>
> +#include <linux/protected_guest.h>
>
> #include <asm/hypervisor.h>
>
> @@ -153,7 +153,7 @@ static unsigned long vmw_port_hb_out(struct rpc_channel *channel,
> unsigned long msg_len = strlen(msg);
>
> /* HB port can't access encrypted memory. */
> - if (hb && !mem_encrypt_active()) {
> + if (hb && !prot_guest_has(PATTR_MEM_ENCRYPT)) {
> unsigned long bp = channel->cookie_high;
>
> si = (uintptr_t) msg;
> @@ -208,7 +208,7 @@ static unsigned long vmw_port_hb_in(struct rpc_channel *channel, char *reply,
> unsigned long si, di, eax, ebx, ecx, edx;
>
> /* HB port can't access encrypted memory */
> - if (hb && !mem_encrypt_active()) {
> + if (hb && !prot_guest_has(PATTR_MEM_ENCRYPT)) {
> unsigned long bp = channel->cookie_low;
>
> si = channel->cookie_high;
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 811a49a95d04..def63a8deab4 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -31,6 +31,7 @@
> #include <linux/irqdomain.h>
> #include <linux/percpu.h>
> #include <linux/io-pgtable.h>
> +#include <linux/protected_guest.h>
> #include <asm/irq_remapping.h>
> #include <asm/io_apic.h>
> #include <asm/apic.h>
> @@ -2178,7 +2179,7 @@ static int amd_iommu_def_domain_type(struct device *dev)
> * active, because some of those devices (AMD GPUs) don't have the
> * encryption bit in their DMA-mask and require remapping.
> */
> - if (!mem_encrypt_active() && dev_data->iommu_v2)
> + if (!prot_guest_has(PATTR_MEM_ENCRYPT) && dev_data->iommu_v2)
> return IOMMU_DOMAIN_IDENTITY;
>
> return 0;
> diff --git a/drivers/iommu/amd/iommu_v2.c b/drivers/iommu/amd/iommu_v2.c
> index f8d4ad421e07..ac359bc98523 100644
> --- a/drivers/iommu/amd/iommu_v2.c
> +++ b/drivers/iommu/amd/iommu_v2.c
> @@ -16,6 +16,7 @@
> #include <linux/wait.h>
> #include <linux/pci.h>
> #include <linux/gfp.h>
> +#include <linux/protected_guest.h>
>
> #include "amd_iommu.h"
>
> @@ -741,7 +742,7 @@ int amd_iommu_init_device(struct pci_dev *pdev, int pasids)
> * When memory encryption is active the device is likely not in a
> * direct-mapped domain. Forbid using IOMMUv2 functionality for now.
> */
> - if (mem_encrypt_active())
> + if (prot_guest_has(PATTR_MEM_ENCRYPT))
> return -ENODEV;
>
> if (!amd_iommu_v2_supported())
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 5419c4b9f27a..ddbedb1b5b6b 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -23,6 +23,7 @@
> #include <linux/property.h>
> #include <linux/fsl/mc.h>
> #include <linux/module.h>
> +#include <linux/protected_guest.h>
> #include <trace/events/iommu.h>
>
> static struct kset *iommu_group_kset;
> @@ -127,7 +128,7 @@ static int __init iommu_subsys_init(void)
> else
> iommu_set_default_translated(false);
>
> - if (iommu_default_passthrough() && mem_encrypt_active()) {
> + if (iommu_default_passthrough() && prot_guest_has(PATTR_MEM_ENCRYPT)) {
> pr_info("Memory encryption detected - Disabling default IOMMU Passthrough\n");
> iommu_set_default_translated(false);
> }
> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> index 9a15334da208..b466f543dc00 100644
> --- a/fs/proc/vmcore.c
> +++ b/fs/proc/vmcore.c
> @@ -26,7 +26,7 @@
> #include <linux/vmalloc.h>
> #include <linux/pagemap.h>
> #include <linux/uaccess.h>
> -#include <linux/mem_encrypt.h>
> +#include <linux/protected_guest.h>
> #include <asm/io.h>
> #include "internal.h"
>
> @@ -177,7 +177,7 @@ ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos)
> */
> ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64 *ppos)
> {
> - return read_from_oldmem(buf, count, ppos, 0, mem_encrypt_active());
> + return read_from_oldmem(buf, count, ppos, 0, prot_guest_has(PATTR_MEM_ENCRYPT));
> }
>
> /*
> @@ -378,7 +378,7 @@ static ssize_t __read_vmcore(char *buffer, size_t buflen, loff_t *fpos,
> buflen);
> start = m->paddr + *fpos - m->offset;
> tmp = read_from_oldmem(buffer, tsz, &start,
> - userbuf, mem_encrypt_active());
> + userbuf, prot_guest_has(PATTR_MEM_ENCRYPT));
> if (tmp < 0)
> return tmp;
> buflen -= tsz;
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index e50df8d8f87e..2e8dee23a624 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -34,7 +34,7 @@
> #include <linux/highmem.h>
> #include <linux/gfp.h>
> #include <linux/scatterlist.h>
> -#include <linux/mem_encrypt.h>
> +#include <linux/protected_guest.h>
> #include <linux/set_memory.h>
> #ifdef CONFIG_DEBUG_FS
> #include <linux/debugfs.h>
> @@ -515,7 +515,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev, phys_addr_t orig_addr,
> if (!mem)
> panic("Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer");
>
> - if (mem_encrypt_active())
> + if (prot_guest_has(PATTR_MEM_ENCRYPT))
> pr_warn_once("Memory encryption is active and system is using DMA bounce buffers\n");
>
> if (mapping_size > alloc_size) {
>
^ permalink raw reply
* Re: [PATCH v3] fpga: dfl: fme: Fix cpu hotplug issue in performance reporting
From: kajoljain @ 2021-08-02 11:46 UTC (permalink / raw)
To: Moritz Fischer
Cc: mark.rutland, maddy, rnsastry, trix, linux-fpga, linuxppc-dev,
linux-kernel, stable, linux-perf-users, atrajeev, will, yilun.xu,
hao.wu
In-Reply-To: <YQezqZcOrePV/FnW@archbook>
On 8/2/21 2:28 PM, Moritz Fischer wrote:
> On Mon, Aug 02, 2021 at 01:15:00PM +0530, kajoljain wrote:
>>
>>
>> On 7/13/21 1:12 PM, Kajol Jain wrote:
>>> The performance reporting driver added cpu hotplug
>>> feature but it didn't add pmu migration call in cpu
>>> offline function.
>>> This can create an issue incase the current designated
>>> cpu being used to collect fme pmu data got offline,
>>> as based on current code we are not migrating fme pmu to
>>> new target cpu. Because of that perf will still try to
>>> fetch data from that offline cpu and hence we will not
>>> get counter data.
>>>
>>> Patch fixed this issue by adding pmu_migrate_context call
>>> in fme_perf_offline_cpu function.
>>>
>>> Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
>>> Tested-by: Xu Yilun <yilun.xu@intel.com>
>>> Acked-by: Wu Hao <hao.wu@intel.com>
>>> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
>>> Cc: stable@vger.kernel.org
>>> ---
>>
>> Any update on this patch? Please let me know if any changes required.
>>
>> Thanks,
>> Kajol Jain
>
> It's in my 'fixes' branch.
Thanks Moritz for informing me.
Thanks,
Kajol Jain
>
> - Moritz
>
^ permalink raw reply
* Re: [PATCH] powerpc/vdso: Don't use r30 to avoid breaking Go lang
From: Michael Ellerman @ 2021-08-02 11:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: pmenzel
In-Reply-To: <20210729131244.2595519-1-mpe@ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> The Go runtime uses r30 for some special value called 'g'. It assumes
> that value will remain unchanged even when calling VDSO functions.
> Although r30 is non-volatile across function calls, the callee is free
> to use it, as long as the callee saves the value and restores it before
> returning.
>
> It used to be true by accident that the VDSO didn't use r30, because the
> VDSO was hand-written asm. When we switched to building the VDSO from C
> the compiler started using r30, at least in some builds, leading to
> crashes in Go. eg:
>
> ~/go/src$ ./all.bash
> Building Go cmd/dist using /usr/lib/go-1.16. (go1.16.2 linux/ppc64le)
> Building Go toolchain1 using /usr/lib/go-1.16.
> go build os/exec: /usr/lib/go-1.16/pkg/tool/linux_ppc64le/compile: signal: segmentation fault
> go build reflect: /usr/lib/go-1.16/pkg/tool/linux_ppc64le/compile: signal: segmentation fault
> go tool dist: FAILED: /usr/lib/go-1.16/bin/go install -gcflags=-l -tags=math_big_pure_go compiler_bootstrap bootstrap/cmd/...: exit status 1
>
> There are patches in flight to fix Go[1], but until they are released
> and widely deployed we can workaround it in the VDSO by avoiding use of
> r30.
>
> Note this only works with GCC, clang does not support -ffixed-rN.
>
> 1: https://go-review.googlesource.com/c/go/+/328110
>
> Fixes: ab037dd87a2f ("powerpc/vdso: Switch VDSO to generic C implementation.")
> Cc: stable@vger.kernel.org # v5.11+
In practice, with GCC 10.3.0, that commit doesn't result in r30 being
used by the compiler.
It's commit 74205b3fc2ef ("powerpc/vdso: Add support for time
namespaces"), which went into v5.13-rc1, which causes r30 to be used in
__c_kernel_clock_gettime():
00000000000006e0 <__c_kernel_clock_gettime>:
6e0: 0f 00 03 28 cmplwi r3,15
6e4: ec 00 81 41 bgt 7d0 <__c_kernel_clock_gettime+0xf0>
6e8: 01 00 20 39 li r9,1
6ec: 30 18 29 7d slw r9,r9,r3
6f0: 83 08 2a 71 andi. r10,r9,2179
6f4: fc 00 82 41 beq 7f0 <__c_kernel_clock_gettime+0x110>
6f8: e4 26 63 78 rldicr r3,r3,4,59
6fc: ff 7f 20 3d lis r9,32767
700: f0 ff c1 fb std r30,-16(r1)
704: f8 ff e1 fb std r31,-8(r1)
708: 14 1a c5 7c add r6,r5,r3
70c: ff ff 2b 61 ori r11,r9,65535
710: 00 00 05 81 lwz r8,0(r5)
714: 01 00 09 71 andi. r9,r8,1
718: 98 00 82 40 bne 7b0 <__c_kernel_clock_gettime+0xd0>
71c: ac 04 20 7c lwsync
720: a6 42 cc 7f mftb r30
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/svm: Don't issue ultracalls if !mem_encrypt_active()
From: Michael Ellerman @ 2021-08-02 11:20 UTC (permalink / raw)
To: Will Deacon, linux-kernel, Konrad Rzeszutek Wilk
Cc: Sachin Sant, Will Deacon, linuxppc-dev, Nicholas Piggin,
Nathan Chancellor, iommu, Claire Chang, Robin Murphy,
Christoph Hellwig
In-Reply-To: <20210730114231.23445-1-will@kernel.org>
Will Deacon <will@kernel.org> writes:
> Commit ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()")
> introduced a set_memory_encrypted() call to swiotlb_exit() so that the
> buffer pages are returned to an encrypted state prior to being freed.
>
> Sachin reports that this leads to the following crash on a Power server:
>
> [ 0.010799] software IO TLB: tearing down default memory pool
> [ 0.010805] ------------[ cut here ]------------
> [ 0.010808] kernel BUG at arch/powerpc/kernel/interrupt.c:98!
>
> Nick spotted that this is because set_memory_encrypted() is issuing an
> ultracall which doesn't exist for the processor, and should therefore
> be gated by mem_encrypt_active() to mirror the x86 implementation.
>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Claire Chang <tientzu@chromium.org>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Fixes: ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()")
> Suggested-by: Nicholas Piggin <npiggin@gmail.com>
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Tested-by: Nathan Chancellor <nathan@kernel.org>
> Link: https://lore.kernel.org/r/1905CD70-7656-42AE-99E2-A31FC3812EAC@linux.vnet.ibm.com/
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> arch/powerpc/platforms/pseries/svm.c | 6 ++++++
> 1 file changed, 6 insertions(+)
Thanks.
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
I assume Konrad will take this via the swiotlb tree?
cheers
^ permalink raw reply
* Re: [PATCH 08/11] mm: Remove the now unused mem_encrypt_active() function
From: Joerg Roedel @ 2021-08-02 10:47 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-s390, Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh,
kvm, Tianyu Lan, x86, kexec, linux-kernel, amd-gfx,
platform-driver-x86, iommu, Andi Kleen, linux-graphics-maintainer,
dri-devel, linux-fsdevel, Borislav Petkov, linuxppc-dev
In-Reply-To: <fc1205e6c5cdd7ef6c4135093fb141018ca2b70d.1627424774.git.thomas.lendacky@amd.com>
On Tue, Jul 27, 2021 at 05:26:11PM -0500, Tom Lendacky wrote:
> The mem_encrypt_active() function has been replaced by prot_guest_has(),
> so remove the implementation.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Joerg Roedel <jroedel@suse.de>
^ permalink raw reply
* Re: [PATCH 09/11] x86/sev: Remove the now unused mem_encrypt_active() function
From: Joerg Roedel @ 2021-08-02 10:46 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-s390, Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh,
kvm, Tianyu Lan, x86, kexec, linux-kernel, amd-gfx,
platform-driver-x86, iommu, Andi Kleen, linux-graphics-maintainer,
dri-devel, linux-fsdevel, Borislav Petkov, Thomas Gleixner,
linuxppc-dev, Ingo Molnar
In-Reply-To: <2e6fb78b7b18437f0e754513bf6312dcba3d1565.1627424774.git.thomas.lendacky@amd.com>
On Tue, Jul 27, 2021 at 05:26:12PM -0500, Tom Lendacky wrote:
> The mem_encrypt_active() function has been replaced by prot_guest_has(),
> so remove the implementation.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Joerg Roedel <jroedel@suse.de>
^ permalink raw reply
* Re: [PATCH 06/11] x86/sev: Replace occurrences of sev_es_active() with prot_guest_has()
From: Joerg Roedel @ 2021-08-02 10:45 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-s390, Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh,
kvm, Tianyu Lan, x86, kexec, linux-kernel, amd-gfx,
platform-driver-x86, iommu, Andi Kleen, linux-graphics-maintainer,
dri-devel, linux-fsdevel, Borislav Petkov, Thomas Gleixner,
linuxppc-dev, Ingo Molnar
In-Reply-To: <ba565128b88661a656fc3972f01bb2e295158a15.1627424774.git.thomas.lendacky@amd.com>
On Tue, Jul 27, 2021 at 05:26:09PM -0500, Tom Lendacky wrote:
> @@ -48,7 +47,7 @@ static void sme_sev_setup_real_mode(struct trampoline_header *th)
> if (prot_guest_has(PATTR_HOST_MEM_ENCRYPT))
> th->flags |= TH_FLAGS_SME_ACTIVE;
>
> - if (sev_es_active()) {
> + if (prot_guest_has(PATTR_GUEST_PROT_STATE)) {
> /*
> * Skip the call to verify_cpu() in secondary_startup_64 as it
> * will cause #VC exceptions when the AP can't handle them yet.
Not sure how TDX will handle AP booting, are you sure it needs this
special setup as well? Otherwise a check for SEV-ES would be better
instead of the generic PATTR_GUEST_PROT_STATE.
Regards,
Joerg
^ permalink raw reply
* Re: [PATCH 05/11] x86/sev: Replace occurrences of sev_active() with prot_guest_has()
From: Joerg Roedel @ 2021-08-02 10:42 UTC (permalink / raw)
To: Tom Lendacky
Cc: Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh, kvm,
Peter Zijlstra, Dave Hansen, dri-devel, platform-driver-x86,
Ard Biesheuvel, linux-s390, Andi Kleen, x86, amd-gfx, Ingo Molnar,
linux-graphics-maintainer, Tianyu Lan, Borislav Petkov,
Andy Lutomirski, Thomas Gleixner, kexec, linux-kernel, iommu,
linux-fsdevel, linuxppc-dev
In-Reply-To: <fa4cdba858e5cb20da2bcd31acf6959ae391bded.1627424774.git.thomas.lendacky@amd.com>
On Tue, Jul 27, 2021 at 05:26:08PM -0500, Tom Lendacky wrote:
> Replace occurrences of sev_active() with the more generic prot_guest_has()
> using PATTR_GUEST_MEM_ENCRYPT, except for in arch/x86/mm/mem_encrypt*.c
> where PATTR_SEV will be used. If future support is added for other memory
> encryption technologies, the use of PATTR_GUEST_MEM_ENCRYPT can be
> updated, as required, to use PATTR_SEV.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Joerg Roedel <jroedel@suse.de>
^ permalink raw reply
* Re: [PATCH 02/11] x86/sev: Add an x86 version of prot_guest_has()
From: Joerg Roedel @ 2021-08-02 10:35 UTC (permalink / raw)
To: Tom Lendacky
Cc: Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh, kvm,
Peter Zijlstra, Dave Hansen, dri-devel, platform-driver-x86,
linux-s390, Andi Kleen, x86, amd-gfx, Ingo Molnar,
linux-graphics-maintainer, Tianyu Lan, Borislav Petkov,
Andy Lutomirski, Thomas Gleixner, kexec, linux-kernel, iommu,
linux-fsdevel, linuxppc-dev
In-Reply-To: <b3e929a77303dd47fd2adc2a1011009d3bfcee20.1627424774.git.thomas.lendacky@amd.com>
On Tue, Jul 27, 2021 at 05:26:05PM -0500, Tom Lendacky wrote:
> Introduce an x86 version of the prot_guest_has() function. This will be
> used in the more generic x86 code to replace vendor specific calls like
> sev_active(), etc.
>
> While the name suggests this is intended mainly for guests, it will
> also be used for host memory encryption checks in place of sme_active().
>
> The amd_prot_guest_has() function does not use EXPORT_SYMBOL_GPL for the
> same reasons previously stated when changing sme_active(), sev_active and
> sme_me_mask to EXPORT_SYBMOL:
> commit 87df26175e67 ("x86/mm: Unbreak modules that rely on external PAGE_KERNEL availability")
> commit 9d5f38ba6c82 ("x86/mm: Unbreak modules that use the DMA API")
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Co-developed-by: Andi Kleen <ak@linux.intel.com>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> Co-developed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Joerg Roedel <jroedel@suse.de>
^ permalink raw reply
* Re: [PATCH 01/11] mm: Introduce a function to check for virtualization protection features
From: Joerg Roedel @ 2021-08-02 10:34 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-s390, Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh,
kvm, Tianyu Lan, x86, kexec, linux-kernel, amd-gfx,
platform-driver-x86, iommu, Andi Kleen, linux-graphics-maintainer,
dri-devel, linux-fsdevel, Borislav Petkov, linuxppc-dev
In-Reply-To: <cbc875b1d2113225c2b44a2384d5b303d0453cf7.1627424774.git.thomas.lendacky@amd.com>
On Tue, Jul 27, 2021 at 05:26:04PM -0500, Tom Lendacky wrote:
> In prep for other protected virtualization technologies, introduce a
> generic helper function, prot_guest_has(), that can be used to check
> for specific protection attributes, like memory encryption. This is
> intended to eliminate having to add multiple technology-specific checks
> to the code (e.g. if (sev_active() || tdx_active())).
>
> Co-developed-by: Andi Kleen <ak@linux.intel.com>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> Co-developed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Joerg Roedel <jroedel@suse.de>
^ 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