* Re: [PATCH v2 1/3] dt-bindings: i2c: mpc: Add fsl,i2c-erratum-a004447 flag
From: Rob Herring @ 2021-05-07 21:49 UTC (permalink / raw)
To: Chris Packham
Cc: devicetree, linux-kernel, wsa, andy.shevchenko, linux-i2c,
andriy.shevchenko, linuxppc-dev
In-Reply-To: <20210507004047.4454-2-chris.packham@alliedtelesis.co.nz>
On Fri, May 07, 2021 at 12:40:45PM +1200, Chris Packham wrote:
> Document the fsl,i2c-erratum-a004447 flag which indicates the presence
> of an i2c erratum on some QorIQ SoCs.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
> index 7b553d559c83..98c6fcf7bf26 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
> @@ -46,6 +46,13 @@ properties:
> description: |
> I2C bus timeout in microseconds
>
> + fsl,i2c-erratum-a004447:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: |
> + Indicates the presence of QorIQ erratum A-004447, which
> + says that the standard i2c recovery scheme mechanism does
> + not work and an alternate implementation is needed.
The problem with adding a property for an errata is you have to update
the dtb. If you use the compatible string, then only an OS update is
needed. That assumes you have specific enough compatible strings.
Rob
^ permalink raw reply
* [RFC 0/12] Unify asm/unaligned.h around struct helper
From: Arnd Bergmann @ 2021-05-07 22:07 UTC (permalink / raw)
To: linux-arch
Cc: Rich Felker, linux-sh, Richard Russon (FlatCap), Amitkumar Karwar,
Russell King, Eric Dumazet, Paul Mackerras, H. Peter Anvin,
sparclinux, Thomas Gleixner, Jonas Bonn, Florian Fainelli,
Yoshinori Sato, x86, James Morris, Ingo Molnar,
Geert Uytterhoeven, linux-arm-kernel, Jakub Kicinski,
Serge E. Hallyn, Arnd Bergmann, Ganapathi Bhat, linuxppc-dev,
Stefan Kristiansson, linux-block, linux-m68k, openrisc,
Borislav Petkov, Stafford Horne, Kalle Valo, Jens Axboe,
John Johansen, Xinming Hu, Vineet Gupta, linux-wireless,
linux-kernel, Vladimir Oltean, linux-ntfs-dev,
linux-security-module, linux-crypto, netdev, Linus Torvalds,
Sharvari Harisangam
From: Arnd Bergmann <arnd@arndb.de>
The get_unaligned()/put_unaligned() helpers are traditionally architecture
specific, with the two main variants being the "access-ok.h" version
that assumes unaligned pointer accesses always work on a particular
architecture, and the "le-struct.h" version that casts the data to a
byte aligned type before dereferencing, for architectures that cannot
always do unaligned accesses in hardware.
Based on the discussion linked below, it appears that the access-ok
version is not realiable on any architecture, but the struct version
probably has no downsides. This series changes the code to use the
same implementation on all architectures, addressing the few exceptions
separately.
I've pushed the patches to the asm-generic git tree for testing.
Arnd
Link: https://lore.kernel.org/lkml/75d07691-1e4f-741f-9852-38c0b4f520bc@synopsys.com/
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
Link: git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git unaligned-rework
Arnd Bergmann (12):
asm-generic: use asm-generic/unaligned.h for most architectures
openrisc: always use unaligned-struct header
sh: remove unaligned access for sh4a
m68k: select CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
powerpc: use linux/unaligned/le_struct.h on LE power7
asm-generic: unaligned: remove byteshift helpers
asm-generic: unaligned always use struct helpers
partitions: msdos: fix one-byte get_unaligned()
apparmor: use get_unaligned() only for multi-byte words
mwifiex: re-fix for unaligned accesses
netpoll: avoid put_unaligned() on single character
asm-generic: simplify asm/unaligned.h
arch/alpha/include/asm/unaligned.h | 12 --
arch/arm/include/asm/unaligned.h | 27 ---
arch/ia64/include/asm/unaligned.h | 12 --
arch/m68k/Kconfig | 1 +
arch/m68k/include/asm/unaligned.h | 26 ---
arch/microblaze/include/asm/unaligned.h | 27 ---
arch/mips/crypto/crc32-mips.c | 2 +-
arch/openrisc/include/asm/unaligned.h | 47 -----
arch/parisc/include/asm/unaligned.h | 6 +-
arch/powerpc/include/asm/unaligned.h | 22 ---
arch/sh/include/asm/unaligned-sh4a.h | 199 --------------------
arch/sh/include/asm/unaligned.h | 13 --
arch/sparc/include/asm/unaligned.h | 11 --
arch/x86/include/asm/unaligned.h | 15 --
arch/xtensa/include/asm/unaligned.h | 29 ---
block/partitions/ldm.h | 2 +-
block/partitions/msdos.c | 2 +-
drivers/net/wireless/marvell/mwifiex/pcie.c | 10 +-
include/asm-generic/unaligned.h | 149 ++++++++++++---
include/linux/unaligned/access_ok.h | 68 -------
include/linux/unaligned/be_byteshift.h | 71 -------
include/linux/unaligned/be_memmove.h | 37 ----
include/linux/unaligned/be_struct.h | 37 ----
include/linux/unaligned/generic.h | 115 -----------
include/linux/unaligned/le_byteshift.h | 71 -------
include/linux/unaligned/le_memmove.h | 37 ----
include/linux/unaligned/le_struct.h | 37 ----
include/linux/unaligned/memmove.h | 46 -----
net/core/netpoll.c | 4 +-
security/apparmor/policy_unpack.c | 2 +-
30 files changed, 137 insertions(+), 1000 deletions(-)
delete mode 100644 arch/alpha/include/asm/unaligned.h
delete mode 100644 arch/arm/include/asm/unaligned.h
delete mode 100644 arch/ia64/include/asm/unaligned.h
delete mode 100644 arch/m68k/include/asm/unaligned.h
delete mode 100644 arch/microblaze/include/asm/unaligned.h
delete mode 100644 arch/openrisc/include/asm/unaligned.h
delete mode 100644 arch/powerpc/include/asm/unaligned.h
delete mode 100644 arch/sh/include/asm/unaligned-sh4a.h
delete mode 100644 arch/sh/include/asm/unaligned.h
delete mode 100644 arch/sparc/include/asm/unaligned.h
delete mode 100644 arch/x86/include/asm/unaligned.h
delete mode 100644 arch/xtensa/include/asm/unaligned.h
delete mode 100644 include/linux/unaligned/access_ok.h
delete mode 100644 include/linux/unaligned/be_byteshift.h
delete mode 100644 include/linux/unaligned/be_memmove.h
delete mode 100644 include/linux/unaligned/be_struct.h
delete mode 100644 include/linux/unaligned/generic.h
delete mode 100644 include/linux/unaligned/le_byteshift.h
delete mode 100644 include/linux/unaligned/le_memmove.h
delete mode 100644 include/linux/unaligned/le_struct.h
delete mode 100644 include/linux/unaligned/memmove.h
Cc: Amitkumar Karwar <amitkarwar@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ganapathi Bhat <ganapathi017@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: James Morris <jmorris@namei.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: John Johansen <john.johansen@canonical.com>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Rich Felker <dalias@libc.org>
Cc: "Richard Russon (FlatCap)" <ldm@flatcap.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Sharvari Harisangam <sharvari.harisangam@nxp.com>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Xinming Hu <huxinming820@gmail.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: linux-crypto@vger.kernel.org
Cc: openrisc@lists.librecores.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-sh@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: linux-ntfs-dev@lists.sourceforge.net
Cc: linux-block@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
--
2.29.2
^ permalink raw reply
* [RFC 05/12] powerpc: use linux/unaligned/le_struct.h on LE power7
From: Arnd Bergmann @ 2021-05-07 22:07 UTC (permalink / raw)
To: linux-arch
Cc: Arnd Bergmann, Vineet Gupta, linuxppc-dev, linux-kernel,
Paul Mackerras, Linus Torvalds
In-Reply-To: <20210507220813.365382-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
Little-endian POWER7 kernels disable
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS because that is not supported on
the hardware, but the kernel still uses direct load/store for explicti
get_unaligned()/put_unaligned().
I assume this is a mistake that leads to power7 having to trap and fix
up all these unaligned accesses at a noticeable performance cost.
The fix is completely trivial, just remove the file and use the
generic version that gets it right.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/include/asm/unaligned.h | 22 ----------------------
1 file changed, 22 deletions(-)
delete mode 100644 arch/powerpc/include/asm/unaligned.h
diff --git a/arch/powerpc/include/asm/unaligned.h b/arch/powerpc/include/asm/unaligned.h
deleted file mode 100644
index ce69c5eff95e..000000000000
--- a/arch/powerpc/include/asm/unaligned.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_POWERPC_UNALIGNED_H
-#define _ASM_POWERPC_UNALIGNED_H
-
-#ifdef __KERNEL__
-
-/*
- * The PowerPC can do unaligned accesses itself based on its endian mode.
- */
-#include <linux/unaligned/access_ok.h>
-#include <linux/unaligned/generic.h>
-
-#ifdef __LITTLE_ENDIAN__
-#define get_unaligned __get_unaligned_le
-#define put_unaligned __put_unaligned_le
-#else
-#define get_unaligned __get_unaligned_be
-#define put_unaligned __put_unaligned_be
-#endif
-
-#endif /* __KERNEL__ */
-#endif /* _ASM_POWERPC_UNALIGNED_H */
--
2.29.2
^ permalink raw reply related
* [RFC 0/12] Unify asm/unaligned.h around struct helper
From: Arnd Bergmann @ 2021-05-07 22:07 UTC (permalink / raw)
To: linux-arch
Cc: Rich Felker, linux-sh, Richard Russon (FlatCap), Amitkumar Karwar,
Russell King, Eric Dumazet, Paul Mackerras, H. Peter Anvin,
sparclinux, Thomas Gleixner, Jonas Bonn, Florian Fainelli,
Yoshinori Sato, x86, James Morris, Ingo Molnar,
Geert Uytterhoeven, linux-arm-kernel, Jakub Kicinski,
Serge E. Hallyn, Arnd Bergmann, Ganapathi Bhat, linuxppc-dev,
Stefan Kristiansson, linux-block, linux-m68k, openrisc,
Borislav Petkov, Stafford Horne, Kalle Valo, Jens Axboe,
John Johansen, Xinming Hu, Vineet Gupta, linux-wireless,
linux-kernel, Vladimir Oltean, linux-ntfs-dev,
linux-security-module, linux-crypto, netdev, Linus Torvalds,
Sharvari Harisangam
In-Reply-To: <20210507220813.365382-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
The get_unaligned()/put_unaligned() helpers are traditionally architecture
specific, with the two main variants being the "access-ok.h" version
that assumes unaligned pointer accesses always work on a particular
architecture, and the "le-struct.h" version that casts the data to a
byte aligned type before dereferencing, for architectures that cannot
always do unaligned accesses in hardware.
Based on the discussion linked below, it appears that the access-ok
version is not realiable on any architecture, but the struct version
probably has no downsides. This series changes the code to use the
same implementation on all architectures, addressing the few exceptions
separately.
I've pushed the patches to the asm-generic git tree for testing.
Arnd
Link: https://lore.kernel.org/lkml/75d07691-1e4f-741f-9852-38c0b4f520bc@synopsys.com/
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
Link: git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git unaligned-rework
Arnd Bergmann (12):
asm-generic: use asm-generic/unaligned.h for most architectures
openrisc: always use unaligned-struct header
sh: remove unaligned access for sh4a
m68k: select CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
powerpc: use linux/unaligned/le_struct.h on LE power7
asm-generic: unaligned: remove byteshift helpers
asm-generic: unaligned always use struct helpers
partitions: msdos: fix one-byte get_unaligned()
apparmor: use get_unaligned() only for multi-byte words
mwifiex: re-fix for unaligned accesses
netpoll: avoid put_unaligned() on single character
asm-generic: simplify asm/unaligned.h
arch/alpha/include/asm/unaligned.h | 12 --
arch/arm/include/asm/unaligned.h | 27 ---
arch/ia64/include/asm/unaligned.h | 12 --
arch/m68k/Kconfig | 1 +
arch/m68k/include/asm/unaligned.h | 26 ---
arch/microblaze/include/asm/unaligned.h | 27 ---
arch/mips/crypto/crc32-mips.c | 2 +-
arch/openrisc/include/asm/unaligned.h | 47 -----
arch/parisc/include/asm/unaligned.h | 6 +-
arch/powerpc/include/asm/unaligned.h | 22 ---
arch/sh/include/asm/unaligned-sh4a.h | 199 --------------------
arch/sh/include/asm/unaligned.h | 13 --
arch/sparc/include/asm/unaligned.h | 11 --
arch/x86/include/asm/unaligned.h | 15 --
arch/xtensa/include/asm/unaligned.h | 29 ---
block/partitions/ldm.h | 2 +-
block/partitions/msdos.c | 2 +-
drivers/net/wireless/marvell/mwifiex/pcie.c | 10 +-
include/asm-generic/unaligned.h | 149 ++++++++++++---
include/linux/unaligned/access_ok.h | 68 -------
include/linux/unaligned/be_byteshift.h | 71 -------
include/linux/unaligned/be_memmove.h | 37 ----
include/linux/unaligned/be_struct.h | 37 ----
include/linux/unaligned/generic.h | 115 -----------
include/linux/unaligned/le_byteshift.h | 71 -------
include/linux/unaligned/le_memmove.h | 37 ----
include/linux/unaligned/le_struct.h | 37 ----
include/linux/unaligned/memmove.h | 46 -----
net/core/netpoll.c | 4 +-
security/apparmor/policy_unpack.c | 2 +-
30 files changed, 137 insertions(+), 1000 deletions(-)
delete mode 100644 arch/alpha/include/asm/unaligned.h
delete mode 100644 arch/arm/include/asm/unaligned.h
delete mode 100644 arch/ia64/include/asm/unaligned.h
delete mode 100644 arch/m68k/include/asm/unaligned.h
delete mode 100644 arch/microblaze/include/asm/unaligned.h
delete mode 100644 arch/openrisc/include/asm/unaligned.h
delete mode 100644 arch/powerpc/include/asm/unaligned.h
delete mode 100644 arch/sh/include/asm/unaligned-sh4a.h
delete mode 100644 arch/sh/include/asm/unaligned.h
delete mode 100644 arch/sparc/include/asm/unaligned.h
delete mode 100644 arch/x86/include/asm/unaligned.h
delete mode 100644 arch/xtensa/include/asm/unaligned.h
delete mode 100644 include/linux/unaligned/access_ok.h
delete mode 100644 include/linux/unaligned/be_byteshift.h
delete mode 100644 include/linux/unaligned/be_memmove.h
delete mode 100644 include/linux/unaligned/be_struct.h
delete mode 100644 include/linux/unaligned/generic.h
delete mode 100644 include/linux/unaligned/le_byteshift.h
delete mode 100644 include/linux/unaligned/le_memmove.h
delete mode 100644 include/linux/unaligned/le_struct.h
delete mode 100644 include/linux/unaligned/memmove.h
Cc: Amitkumar Karwar <amitkarwar@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ganapathi Bhat <ganapathi017@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: James Morris <jmorris@namei.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: John Johansen <john.johansen@canonical.com>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Rich Felker <dalias@libc.org>
Cc: "Richard Russon (FlatCap)" <ldm@flatcap.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Sharvari Harisangam <sharvari.harisangam@nxp.com>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Xinming Hu <huxinming820@gmail.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: linux-crypto@vger.kernel.org
Cc: openrisc@lists.librecores.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-sh@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: linux-ntfs-dev@lists.sourceforge.net
Cc: linux-block@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
--
2.29.2
^ permalink raw reply
* Re: [PATCH] lockdown,selinux: fix bogus SELinux lockdown permission checks
From: Casey Schaufler @ 2021-05-07 22:17 UTC (permalink / raw)
To: Ondrej Mosnacek, linux-security-module, James Morris
Cc: selinux, netdev, Stephen Smalley, linux-kernel, Steven Rostedt,
Casey Schaufler, Ingo Molnar, linux-fsdevel, bpf, linuxppc-dev
In-Reply-To: <20210507114048.138933-1-omosnace@redhat.com>
On 5/7/2021 4:40 AM, Ondrej Mosnacek wrote:
> Commit 59438b46471a ("security,lockdown,selinux: implement SELinux
> lockdown") added an implementation of the locked_down LSM hook to
> SELinux, with the aim to restrict which domains are allowed to perform
> operations that would breach lockdown.
>
> However, in several places the security_locked_down() hook is called in
> situations where the current task isn't doing any action that would
> directly breach lockdown, leading to SELinux checks that are basically
> bogus.
>
> Since in most of these situations converting the callers such that
> security_locked_down() is called in a context where the current task
> would be meaningful for SELinux is impossible or very non-trivial (and
> could lead to TOCTOU issues for the classic Lockdown LSM
> implementation), fix this by adding a separate hook
> security_locked_down_globally()
This is a poor solution to the stated problem. Rather than adding
a new hook you should add the task as a parameter to the existing hook
and let the security modules do as they will based on its value.
If the caller does not have an appropriate task it should pass NULL.
The lockdown LSM can ignore the task value and SELinux can make its
own decision based on the task value passed.
> that is to be used in such situations
> and convert all these problematic callers to call this hook instead. The
> new hook is then left unimplemented in SELinux and in Lockdown LSM it is
> backed by the same implementation as the locked_down hook.
>
> The callers migrated to the new hook are:
> 1. arch/powerpc/xmon/xmon.c
> Here the hook seems to be called from non-task context and is only
> used for redacting some sensitive values from output sent to
> userspace.
> 2. fs/tracefs/inode.c:tracefs_create_file()
> Here the call is used to prevent creating new tracefs entries when
> the kernel is locked down. Assumes that locking down is one-way -
> i.e. if the hook returns non-zero once, it will never return zero
> again, thus no point in creating these files.
> 3. kernel/trace/bpf_trace.c:bpf_probe_read_kernel{,_str}_common()
> Called when a BPF program calls a helper that could leak kernel
> memory. The task context is not relevant here, since the program
> may very well be run in the context of a different task than the
> consumer of the data.
> See: https://bugzilla.redhat.com/show_bug.cgi?id=1955585
> 4. net/xfrm/xfrm_user.c:copy_to_user_*()
> Here a cryptographic secret is redacted based on the value returned
> from the hook. There are two possible actions that may lead here:
> a) A netlink message XFRM_MSG_GETSA with NLM_F_DUMP set - here the
> task context is relevant, since the dumped data is sent back to
> the current task.
> b) When deleting an SA via XFRM_MSG_DELSA, the dumped SAs are
> broadcasted to tasks subscribed to XFRM events - here the
> SELinux check is not meningful as the current task's creds do
> not represent the tasks that could potentially see the secret.
> It really doesn't seem worth it to try to preserve the check in the
> a) case, since the eventual leak can be circumvented anyway via b),
> plus there is no way for the task to indicate that it doesn't care
> about the actual key value, so the check could generate a lot of
> noise.
>
> Fixes: 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown")
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> ---
> arch/powerpc/xmon/xmon.c | 4 ++--
> fs/tracefs/inode.c | 2 +-
> include/linux/lsm_hook_defs.h | 1 +
> include/linux/security.h | 5 +++++
> kernel/trace/bpf_trace.c | 4 ++--
> net/xfrm/xfrm_user.c | 2 +-
> security/lockdown/lockdown.c | 1 +
> security/security.c | 6 ++++++
> 8 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 3fe37495f63d..a4bad825d424 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -298,7 +298,7 @@ static bool xmon_is_locked_down(void)
> static bool lockdown;
>
> if (!lockdown) {
> - lockdown = !!security_locked_down(LOCKDOWN_XMON_RW);
> + lockdown = !!security_locked_down_globally(LOCKDOWN_XMON_RW);
> if (lockdown) {
> printf("xmon: Disabled due to kernel lockdown\n");
> xmon_is_ro = true;
> @@ -306,7 +306,7 @@ static bool xmon_is_locked_down(void)
> }
>
> if (!xmon_is_ro) {
> - xmon_is_ro = !!security_locked_down(LOCKDOWN_XMON_WR);
> + xmon_is_ro = !!security_locked_down_globally(LOCKDOWN_XMON_WR);
> if (xmon_is_ro)
> printf("xmon: Read-only due to kernel lockdown\n");
> }
> diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
> index 4b83cbded559..07241435efec 100644
> --- a/fs/tracefs/inode.c
> +++ b/fs/tracefs/inode.c
> @@ -396,7 +396,7 @@ struct dentry *tracefs_create_file(const char *name, umode_t mode,
> struct dentry *dentry;
> struct inode *inode;
>
> - if (security_locked_down(LOCKDOWN_TRACEFS))
> + if (security_locked_down_globally(LOCKDOWN_TRACEFS))
> return NULL;
>
> if (!(mode & S_IFMT))
> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
> index 477a597db013..d6e2a6b59277 100644
> --- a/include/linux/lsm_hook_defs.h
> +++ b/include/linux/lsm_hook_defs.h
> @@ -390,6 +390,7 @@ LSM_HOOK(void, LSM_RET_VOID, bpf_prog_free_security, struct bpf_prog_aux *aux)
> #endif /* CONFIG_BPF_SYSCALL */
>
> LSM_HOOK(int, 0, locked_down, enum lockdown_reason what)
> +LSM_HOOK(int, 0, locked_down_globally, enum lockdown_reason what)
>
> #ifdef CONFIG_PERF_EVENTS
> LSM_HOOK(int, 0, perf_event_open, struct perf_event_attr *attr, int type)
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 8aeebd6646dc..e683dee84f46 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -468,6 +468,7 @@ int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen);
> int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
> int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen);
> int security_locked_down(enum lockdown_reason what);
> +int security_locked_down_globally(enum lockdown_reason what);
> #else /* CONFIG_SECURITY */
>
> static inline int call_blocking_lsm_notifier(enum lsm_event event, void *data)
> @@ -1329,6 +1330,10 @@ static inline int security_locked_down(enum lockdown_reason what)
> {
> return 0;
> }
> +static inline int security_locked_down_globally(enum lockdown_reason what)
> +{
> + return 0;
> +}
> #endif /* CONFIG_SECURITY */
>
> #if defined(CONFIG_SECURITY) && defined(CONFIG_WATCH_QUEUE)
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index b0c45d923f0f..f43bca95b261 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -215,7 +215,7 @@ const struct bpf_func_proto bpf_probe_read_user_str_proto = {
> static __always_inline int
> bpf_probe_read_kernel_common(void *dst, u32 size, const void *unsafe_ptr)
> {
> - int ret = security_locked_down(LOCKDOWN_BPF_READ);
> + int ret = security_locked_down_globally(LOCKDOWN_BPF_READ);
>
> if (unlikely(ret < 0))
> goto fail;
> @@ -246,7 +246,7 @@ const struct bpf_func_proto bpf_probe_read_kernel_proto = {
> static __always_inline int
> bpf_probe_read_kernel_str_common(void *dst, u32 size, const void *unsafe_ptr)
> {
> - int ret = security_locked_down(LOCKDOWN_BPF_READ);
> + int ret = security_locked_down_globally(LOCKDOWN_BPF_READ);
>
> if (unlikely(ret < 0))
> goto fail;
> diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
> index 5a0ef4361e43..5a56f74262d8 100644
> --- a/net/xfrm/xfrm_user.c
> +++ b/net/xfrm/xfrm_user.c
> @@ -851,7 +851,7 @@ static int copy_user_offload(struct xfrm_state_offload *xso, struct sk_buff *skb
> static bool xfrm_redact(void)
> {
> return IS_ENABLED(CONFIG_SECURITY) &&
> - security_locked_down(LOCKDOWN_XFRM_SECRET);
> + security_locked_down_globally(LOCKDOWN_XFRM_SECRET);
> }
>
> static int copy_to_user_auth(struct xfrm_algo_auth *auth, struct sk_buff *skb)
> diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
> index 87cbdc64d272..4ac172eaa4b7 100644
> --- a/security/lockdown/lockdown.c
> +++ b/security/lockdown/lockdown.c
> @@ -73,6 +73,7 @@ static int lockdown_is_locked_down(enum lockdown_reason what)
>
> static struct security_hook_list lockdown_hooks[] __lsm_ro_after_init = {
> LSM_HOOK_INIT(locked_down, lockdown_is_locked_down),
> + LSM_HOOK_INIT(locked_down_globally, lockdown_is_locked_down),
> };
>
> static int __init lockdown_lsm_init(void)
> diff --git a/security/security.c b/security/security.c
> index 5ac96b16f8fa..b9b990681ae9 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -2547,6 +2547,12 @@ int security_locked_down(enum lockdown_reason what)
> }
> EXPORT_SYMBOL(security_locked_down);
>
> +int security_locked_down_globally(enum lockdown_reason what)
> +{
> + return call_int_hook(locked_down_globally, 0, what);
> +}
> +EXPORT_SYMBOL(security_locked_down_globally);
> +
> #ifdef CONFIG_PERF_EVENTS
> int security_perf_event_open(struct perf_event_attr *attr, int type)
> {
^ permalink raw reply
* Re: [RESEND PATCH v4 10/11] powerpc: Protect patching_mm with a lock
From: Peter Zijlstra @ 2021-05-07 22:26 UTC (permalink / raw)
To: Christopher M. Riedl; +Cc: tglx, x86, linuxppc-dev, linux-hardening, keescook
In-Reply-To: <CB7A6IWZTDUL.17HEAW6KQEYCD@oc8246131445.ibm.com>
On Fri, May 07, 2021 at 03:03:51PM -0500, Christopher M. Riedl wrote:
> On Thu May 6, 2021 at 5:51 AM CDT, Peter Zijlstra wrote:
> > On Wed, May 05, 2021 at 11:34:51PM -0500, Christopher M. Riedl wrote:
> > > Powerpc allows for multiple CPUs to patch concurrently. When patching
> > > with STRICT_KERNEL_RWX a single patching_mm is allocated for use by all
> > > CPUs for the few times that patching occurs. Use a spinlock to protect
> > > the patching_mm from concurrent use.
> > >
> > > Modify patch_instruction() to acquire the lock, perform the patch op,
> > > and then release the lock.
> > >
> > > Also introduce {lock,unlock}_patching() along with
> > > patch_instruction_unlocked() to avoid per-iteration lock overhead when
> > > patch_instruction() is called in a loop. A follow-up patch converts some
> > > uses of patch_instruction() to use patch_instruction_unlocked() instead.
> >
> > x86 uses text_mutex for all this, why not do the same?
>
> I wasn't entirely sure if there is a problem with potentially going to
> sleep in some of the places where patch_instruction() is called - the
> spinlock avoids that (hypothetical) problem.
So I'm not saying you like have to do this; but I did wonder if there's
a reason not to, and given you didn't mention it, I had to ask.
> I just tried switching to text_mutex and at least on a P9 machine the
> series boots w/ the Hash and Radix MMUs (with some lockdep errors). I
> can rework this in the next version to use text_mutex if I don't find
> any new problems with more extensive testing. It does mean more changes
> to use patch_instruction_unlocked() in kprobe/optprobe/ftace in
> arch/powerpc since iirc those are called with text_mutex already held.
The x86 text_poke() has a lockdep_assert_held(&text_mutex) in to make
sure nobody 'forgets' :-)
^ permalink raw reply
* [PATCH -next] crypto: nx842: add missing MODULE_DEVICE_TABLE
From: Bixuan Cui @ 2021-05-08 3:14 UTC (permalink / raw)
To: cuibixuan, Haren Myneni, Herbert Xu, David S. Miller,
Michael Ellerman
Cc: kernel-janitors, linuxppc-dev, linux-crypto
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
---
drivers/crypto/nx/nx-842-pseries.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/nx/nx-842-pseries.c b/drivers/crypto/nx/nx-842-pseries.c
index cc8dd3072b8b..8ee547ee378e 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -1069,6 +1069,7 @@ static const struct vio_device_id nx842_vio_driver_ids[] = {
{"ibm,compression-v1", "ibm,compression"},
{"", ""},
};
+MODULE_DEVICE_TABLE(vio, nx842_vio_driver_ids);
static struct vio_driver nx842_vio_driver = {
.name = KBUILD_MODNAME,
^ permalink raw reply related
* [PATCH v3] powerpc/papr_scm: Reduce error severity if nvdimm stats inaccessible
From: Vaibhav Jain @ 2021-05-08 4:36 UTC (permalink / raw)
To: linuxppc-dev, linux-nvdimm
Cc: Santosh Sivaraj, Aneesh Kumar K . V, Vaibhav Jain, Dan Williams,
Ira Weiny
Currently drc_pmem_qeury_stats() generates a dev_err in case
"Enable Performance Information Collection" feature is disabled from
HMC or performance stats are not available for an nvdimm. The error is
of the form below:
papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
performance stats, Err:-10
This error message confuses users as it implies a possible problem
with the nvdimm even though its due to a disabled/unavailable
feature. We fix this by explicitly handling the H_AUTHORITY and
H_UNSUPPORTED errors from the H_SCM_PERFORMANCE_STATS hcall.
In case of H_AUTHORITY error an info message is logged instead of an
error, saying that "Permission denied while accessing performance
stats" and an EPERM error is returned back.
In case of H_UNSUPPORTED error we return a EOPNOTSUPP error back from
drc_pmem_query_stats() indicating that performance stats-query
operation is not supported on this nvdimm.
Fixes: 2d02bf835e57('powerpc/papr_scm: Fetch nvdimm performance stats from PHYP')
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
Changelog
v3:
* Return EOPNOTSUPP error in case of H_UNSUPPORTED [ Ira ]
* Return EPERM in case of H_AUTHORITY [ Ira ]
* Updated patch description
v2:
* Updated the message logged in case of H_AUTHORITY error [ Ira ]
* Switched from dev_warn to dev_info in case of H_AUTHORITY error.
* Instead of -EPERM return -EACCESS for H_AUTHORITY error.
* Added explicit handling of H_UNSUPPORTED error.
---
arch/powerpc/platforms/pseries/papr_scm.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index ef26fe40efb0..e2b69cc3beaf 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -310,6 +310,13 @@ static ssize_t drc_pmem_query_stats(struct papr_scm_priv *p,
dev_err(&p->pdev->dev,
"Unknown performance stats, Err:0x%016lX\n", ret[0]);
return -ENOENT;
+ } else if (rc == H_AUTHORITY) {
+ dev_info(&p->pdev->dev,
+ "Permission denied while accessing performance stats");
+ return -EPERM;
+ } else if (rc == H_UNSUPPORTED) {
+ dev_dbg(&p->pdev->dev, "Performance stats unsupported\n");
+ return -EOPNOTSUPP;
} else if (rc != H_SUCCESS) {
dev_err(&p->pdev->dev,
"Failed to query performance stats, Err:%lld\n", rc);
--
2.31.1
^ permalink raw reply related
* [PATCH] powerpc/legacy_serial: Fix UBSAN: array-index-out-of-bounds
From: Christophe Leroy @ 2021-05-08 6:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, pmenzel
Cc: linuxppc-dev, linux-kernel
UBSAN complains when a pointer is calculated with invalid
'legacy_serial_console' index, allthough the index is verified
before dereferencing the pointer.
Fix it by checking 'legacy_serial_console' validity before
calculating pointers.
Fixes: 0bd3f9e953bd ("powerpc/legacy_serial: Use early_ioremap()")
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/legacy_serial.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 8b2c1a8553a0..1c2e09e1d59b 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -354,15 +354,12 @@ static void __init setup_legacy_serial_console(int console)
udbg_uart_setup(info->speed, info->clock);
}
-static int __init ioremap_legacy_serial_console(void)
+static int __init do_ioremap_legacy_serial_console(int console)
{
- struct legacy_serial_info *info = &legacy_serial_infos[legacy_serial_console];
- struct plat_serial8250_port *port = &legacy_serial_ports[legacy_serial_console];
+ struct legacy_serial_info *info = &legacy_serial_infos[console];
+ struct plat_serial8250_port *port = &legacy_serial_ports[console];
void __iomem *vaddr;
- if (legacy_serial_console < 0)
- return 0;
-
if (!info->early_addr)
return 0;
@@ -376,6 +373,13 @@ static int __init ioremap_legacy_serial_console(void)
return 0;
}
+
+static int __init ioremap_legacy_serial_console(void)
+{
+ if (legacy_serial_console < 0)
+ return 0;
+ return do_ioremap_legacy_serial_console(legacy_serial_console);
+}
early_initcall(ioremap_legacy_serial_console);
/*
--
2.25.0
^ permalink raw reply related
* Re: Kernel crosscompilers
From: Christophe Leroy @ 2021-05-08 6:46 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev@ozlabs.org, Segher Boessenkool
In-Reply-To: <CAK8P3a3OdcSQQGKxRob3A6qfh8tVD1JtLdcTp9i25SizqWpiXA@mail.gmail.com>
Le 06/05/2021 à 16:17, Arnd Bergmann a écrit :
> On Thu, May 6, 2021 at 2:42 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>> Hello Arnd,
>>
>> May I ask you whether you plan to build cross compilers based on GCC 11.1 at
>> https://mirrors.edge.kernel.org/pub/tools/crosstool/ ?
>
> Hi Christophe,
>
> I've built a snapshot a few days before the release, that one is
> identical to 11.1
> except for the reported version number. I've tried to ask around for
> help testing
> this, but so far I have not heard from anyone.
>
> Building a new set of compilers takes around a day on my build box, so I want
> to make sure I don't have to do it more often than necessary. If you are able
> to give the binaries a spin, preferably on a ppc64le or arm64 host, please let
> me know how it goes and I'll rebuilt them on the release tag.
>
Hi Arnd,
I don't have any ppc or arm host I can build on.
I'm building on x86 for powerpc embedded boards.
I have tried your GCC 11 snapshot, I get something booting but it crashes when launching init.
[ 7.368410] init[1]: bad frame in sys_sigreturn: 7fb2fd60 nip 001083cc lr 001083c4
[ 7.376283] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 7.383680] CPU: 0 PID: 1 Comm: init Not tainted 5.12.0-s3k-dev-16316-g9e799d5df185 #5054
[ 7.391767] Call Trace:
[ 7.394174] [c9023db0] [c00211e8] panic+0x130/0x304 (unreliable)
[ 7.400112] [c9023e10] [c0024e68] do_exit+0x874/0x910
[ 7.405104] [c9023e50] [c0024f80] do_group_exit+0x40/0xc4
[ 7.410440] [c9023e60] [c0033334] get_signal+0x1d8/0x93c
[ 7.415689] [c9023ec0] [c0007f34] do_notify_resume+0x6c/0x314
[ 7.421369] [c9023f20] [c000d580] syscall_exit_prepare+0x120/0x184
[ 7.427479] [c9023f30] [c001101c] ret_from_syscall+0xc/0x28
Something is going wrong with asm goto output. I implemented get_user() helpers with asm goto this
cycle (commit 5cd29b1fd3e8). I tested it with CLANG before submitting, it was working.
Seems like there is something wrong with it with GCC11. When forcing CONFIG_CC_HAS_ASM_GOTO_OUTPUT
to 'n', the kernel boots ok.
Christophe
^ permalink raw reply
* Re: Kernel crosscompilers
From: Christophe Leroy @ 2021-05-08 9:22 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev@ozlabs.org, Segher Boessenkool
In-Reply-To: <19e791d9-3226-4c13-b6e8-cdabdaaa0268@csgroup.eu>
Le 08/05/2021 à 08:46, Christophe Leroy a écrit :
>
>
> Le 06/05/2021 à 16:17, Arnd Bergmann a écrit :
>> On Thu, May 6, 2021 at 2:42 PM Christophe Leroy
>> <christophe.leroy@csgroup.eu> wrote:
>>>
>>> Hello Arnd,
>>>
>>> May I ask you whether you plan to build cross compilers based on GCC 11.1 at
>>> https://mirrors.edge.kernel.org/pub/tools/crosstool/ ?
>>
>> Hi Christophe,
>>
>> I've built a snapshot a few days before the release, that one is
>> identical to 11.1
>> except for the reported version number. I've tried to ask around for
>> help testing
>> this, but so far I have not heard from anyone.
>>
>> Building a new set of compilers takes around a day on my build box, so I want
>> to make sure I don't have to do it more often than necessary. If you are able
>> to give the binaries a spin, preferably on a ppc64le or arm64 host, please let
>> me know how it goes and I'll rebuilt them on the release tag.
>>
>
> Hi Arnd,
>
> I don't have any ppc or arm host I can build on.
> I'm building on x86 for powerpc embedded boards.
>
> I have tried your GCC 11 snapshot, I get something booting but it crashes when launching init.
>
> [ 7.368410] init[1]: bad frame in sys_sigreturn: 7fb2fd60 nip 001083cc lr 001083c4
> [ 7.376283] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 7.383680] CPU: 0 PID: 1 Comm: init Not tainted 5.12.0-s3k-dev-16316-g9e799d5df185 #5054
> [ 7.391767] Call Trace:
> [ 7.394174] [c9023db0] [c00211e8] panic+0x130/0x304 (unreliable)
> [ 7.400112] [c9023e10] [c0024e68] do_exit+0x874/0x910
> [ 7.405104] [c9023e50] [c0024f80] do_group_exit+0x40/0xc4
> [ 7.410440] [c9023e60] [c0033334] get_signal+0x1d8/0x93c
> [ 7.415689] [c9023ec0] [c0007f34] do_notify_resume+0x6c/0x314
> [ 7.421369] [c9023f20] [c000d580] syscall_exit_prepare+0x120/0x184
> [ 7.427479] [c9023f30] [c001101c] ret_from_syscall+0xc/0x28
>
> Something is going wrong with asm goto output. I implemented get_user() helpers with asm goto this
> cycle (commit 5cd29b1fd3e8). I tested it with CLANG before submitting, it was working.
>
> Seems like there is something wrong with it with GCC11. When forcing CONFIG_CC_HAS_ASM_GOTO_OUTPUT
> to 'n', the kernel boots ok.
>
I found the problem, that's due to r10 register being reused by GCC in the copy loop below:
10: 7d 09 03 a6 mtctr r8
14: 80 ca 00 00 lwz r6,0(r10)
18: 80 ea 00 04 lwz r7,4(r10)
1c: 90 c9 00 08 stw r6,8(r9)
20: 90 e9 00 0c stw r7,12(r9)
24: 39 0a 00 08 addi r8,r10,8
28: 39 29 00 08 addi r9,r9,8
=>2c: 81 4a 00 08 lwz r10,8(r10)
30: 81 6a 00 0c lwz r11,12(r10)
34: 91 49 00 08 stw r10,8(r9)
38: 91 69 00 0c stw r11,12(r9)
3c: 39 48 00 08 addi r10,r8,8
40: 39 29 00 08 addi r9,r9,8
44: 42 00 ff d0 bdnz 14 <__unsafe_restore_general_regs+0x14>
earlyclobber modifier is missing in the CONFIG_CC_HAS_ASM_GOTO_OUTPUT version of __get_user_asm2_goto().
This is not a GCC bug, with that fixed my board is working OK.
Christophe
^ permalink raw reply
* [PATCH] powerpc/uaccess: Fix __get_user() with CONFIG_CC_HAS_ASM_GOTO_OUTPUT
From: Christophe Leroy @ 2021-05-08 9:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
Building kernel mainline with GCC 11 leads to following failure
when starting 'init':
init[1]: bad frame in sys_sigreturn: 7ff5a900 nip 001083cc lr 001083c4
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
This is an issue due to a segfault happening in
__unsafe_restore_general_regs() in a loop copying registers from user
to kernel:
10: 7d 09 03 a6 mtctr r8
14: 80 ca 00 00 lwz r6,0(r10)
18: 80 ea 00 04 lwz r7,4(r10)
1c: 90 c9 00 08 stw r6,8(r9)
20: 90 e9 00 0c stw r7,12(r9)
24: 39 0a 00 08 addi r8,r10,8
28: 39 29 00 08 addi r9,r9,8
2c: 81 4a 00 08 lwz r10,8(r10) <== r10 is clobbered here
30: 81 6a 00 0c lwz r11,12(r10)
34: 91 49 00 08 stw r10,8(r9)
38: 91 69 00 0c stw r11,12(r9)
3c: 39 48 00 08 addi r10,r8,8
40: 39 29 00 08 addi r9,r9,8
44: 42 00 ff d0 bdnz 14 <__unsafe_restore_general_regs+0x14>
As shown above, this is due to r10 being re-used by GCC. This didn't
happen with CLANG.
This is fixed by tagging 'x' output as an earlyclobber operand in
__get_user_asm2_goto().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/uaccess.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index a09e4240c5b1..22c79ab40006 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -157,7 +157,7 @@ do { \
"2: lwz%X1 %L0, %L1\n" \
EX_TABLE(1b, %l2) \
EX_TABLE(2b, %l2) \
- : "=r" (x) \
+ : "=&r" (x) \
: "m" (*addr) \
: \
: label)
--
2.25.0
^ permalink raw reply related
* [PATCH] powerpc/signal: Fix possible build failure with unsafe_copy_fpr_{to/from}_user
From: Christophe Leroy @ 2021-05-08 9:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
When neither CONFIG_VSX nor CONFIG_PPC_FPU_REGS are selected,
unsafe_copy_fpr_to_user() and unsafe_copy_fpr_from_user() are
doing nothing.
Then, unless the 'label' operand is used elsewhere, GCC complains
about it being defined but not used.
To fix that, add an impossible 'goto label'.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/signal.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
index f4aafa337c2e..1f07317964e4 100644
--- a/arch/powerpc/kernel/signal.h
+++ b/arch/powerpc/kernel/signal.h
@@ -166,9 +166,9 @@ copy_ckfpr_from_user(struct task_struct *task, void __user *from)
}
#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
#else
-#define unsafe_copy_fpr_to_user(to, task, label) do { } while (0)
+#define unsafe_copy_fpr_to_user(to, task, label) do { if (0) goto label;} while (0)
-#define unsafe_copy_fpr_from_user(task, from, label) do { } while (0)
+#define unsafe_copy_fpr_from_user(task, from, label) do { if (0) goto label;} while (0)
static inline unsigned long
copy_fpr_to_user(void __user *to, struct task_struct *task)
--
2.25.0
^ permalink raw reply related
* Re: Kernel crosscompilers
From: Arnd Bergmann @ 2021-05-08 9:37 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1bf8523a-848a-7686-c179-7bedb18979ac@csgroup.eu>
On Sat, May 8, 2021 at 11:22 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> Le 08/05/2021 à 08:46, Christophe Leroy a écrit :
> >
> > I don't have any ppc or arm host I can build on.
> > I'm building on x86 for powerpc embedded boards.
> >
> > I have tried your GCC 11 snapshot, I get something booting but it crashes when launching init.
> >
...
> > Seems like there is something wrong with it with GCC11. When forcing CONFIG_CC_HAS_ASM_GOTO_OUTPUT
> > to 'n', the kernel boots ok.
> >
>
> I found the problem, that's due to r10 register being reused by GCC in the copy loop below:
Ok, thanks for testing. I'll try to rebuild the release tag in the
next few days.
Arnd
^ permalink raw reply
* Re: Kernel crosscompilers
From: Arnd Bergmann @ 2021-05-08 9:43 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <19e791d9-3226-4c13-b6e8-cdabdaaa0268@csgroup.eu>
On Sat, May 8, 2021 at 8:46 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
> Something is going wrong with asm goto output. I implemented get_user() helpers with asm goto this
> cycle (commit 5cd29b1fd3e8). I tested it with CLANG before submitting, it was working.
BTW, can you point me to those patches? I think it would be nice if we
could eventually
converge parts of get_user()/put_user() implementation on something
that works for all
architectures, we do seem to rewrite these way too often. Ideally we'd
have something
in asm-generic that provides all the wrappers, and just requires an
architecture to
implement the inline asm helpers for each of the sizes.
Arnd
^ permalink raw reply
* [PATCH 1/1] powerpc/ps3: Remove a couple of unneeded semicolons
From: Zhen Lei @ 2021-05-08 9:51 UTC (permalink / raw)
To: Geoff Levand, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev, linux-kernel
Cc: Zhen Lei
The semicolon immediately following '}' is unneeded.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
arch/powerpc/platforms/ps3/system-bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/system-bus.c b/arch/powerpc/platforms/ps3/system-bus.c
index b431f41c6cb53ab..5c739267ddd2174 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -603,7 +603,7 @@ static dma_addr_t ps3_ioc0_map_page(struct device *_dev, struct page *page,
default:
/* not happned */
BUG();
- };
+ }
result = ps3_dma_map(dev->d_region, (unsigned long)ptr, size,
&bus_addr, iopte_flag);
@@ -762,7 +762,7 @@ int ps3_system_bus_device_register(struct ps3_system_bus_device *dev)
break;
default:
BUG();
- };
+ }
dev->core.of_node = NULL;
set_dev_node(&dev->core, 0);
--
2.26.0.106.g9fadedd
^ permalink raw reply related
* Re: [PATCH 4/4] powerpc/powernv: Remove POWER9 PVR version check for entry and uaccess flushes
From: Nicholas Piggin @ 2021-05-08 10:00 UTC (permalink / raw)
To: Joel Stanley; +Cc: linuxppc-dev
In-Reply-To: <CACPK8XeyEaj-0LUa=YMT1WXn=_cQkDXH9xLiVARGCwZANsRk=A@mail.gmail.com>
Excerpts from Joel Stanley's message of May 5, 2021 11:43 am:
> On Tue, 4 May 2021 at 09:16, Nicholas Piggin <npiggin@gmail.com> wrote:
>>
>> Excerpts from Joel Stanley's message of May 4, 2021 10:51 am:
>> > On Mon, 3 May 2021 at 13:04, Nicholas Piggin <npiggin@gmail.com> wrote:
>> >>
>> >> These aren't necessarily POWER9 only, and it's not to say some new
>> >> vulnerability may not get discovered on other processors for which
>> >> we would like the flexibility of having the workaround enabled by
>> >> firmware.
>> >>
>> >> Remove the restriction that they only apply to POWER9.
>> >
>> > I was wondering how these worked which led me to reviewing your patch.
>> > From what I could see, these are enabled by default (SEC_FTR_DEFAULT
>> > in arch/powerpc/include/asm/security_features.h), so unless all
>> > non-POWER9 machines have set the "please don't" bit in their firmware
>> > this patch will enable the feature for those machines. Is that what
>> > you wanted?
>>
>> Yes. POWER7/8 should be affected (it's similar mechanism that requires
>> the meltdown RFI flush, which those processors need).
>>
>> POWER10 we haven't released a bare metal firmware with the right bits
>> yet. Not urgent at the moment but wouldn't hurt to specify them and
>> add the Linux code for them.
>
> Thanks for the explanation. This could go in the commit message if you re-spin.
>
> Reviewed-by: Joel Stanley <joel@jms.id.au>
>
I was talking about the same thing with Michael and he dug up an old
email chain that proves me wrong. P7/8 are actually slightly different.
I'm not sure what I can explain of it in public unfortunately.
How about this?
---
These aren't necessarily POWER9 only, and it's not to say some new
vulnerability may not get discovered on other processors for which
we would like the flexibility of having the workaround enabled by
firmware.
Remove the restriction that the workarounds only apply to POWER9.
However POWER7 and POWER8 are not affected, and they may not have
older firmware that does not advertise this, so clear these workarounds
manually.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/powernv/setup.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index a8db3f153063..874fb016384a 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -123,10 +123,14 @@ static void pnv_setup_security_mitigations(void)
}
/*
- * If we are non-Power9 bare metal, we don't need to flush on kernel
- * entry or after user access: they fix a P9 specific vulnerability.
+ * The issues addressed by the entry and uaccess flush don't affect P7
+ * or P8, so on bare metal disable them explicitly in case firmware
+ * does not include these bits. POWER9 and newer processors should
+ * have the right firmware bits.
*/
- if (!pvr_version_is(PVR_POWER9)) {
+ if (pvr_version_is(PVR_POWER7) || pvr_version_is(PVR_POWER7p) ||
+ pvr_version_is(PVR_POWER8E) || pvr_version_is(PVR_POWER8NVL) ||
+ pvr_version_is(PVR_POWER8)) {
security_ftr_clear(SEC_FTR_L1D_FLUSH_ENTRY);
security_ftr_clear(SEC_FTR_L1D_FLUSH_UACCESS);
}
--
2.23.0
^ permalink raw reply related
* [PATCH v2 1/4] powerpc/pseries: Fix hcall tracing recursion in pv queued spinlocks
From: Nicholas Piggin @ 2021-05-08 10:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Naveen N . Rao, Nicholas Piggin
In-Reply-To: <20210508101455.1578318-1-npiggin@gmail.com>
The paravit queued spinlock slow path adds itself to the queue then
calls pv_wait to wait for the lock to become free. This is implemented
by calling H_CONFER to donate cycles.
When hcall tracing is enabled, this H_CONFER call can lead to a spin
lock being taken in the tracing code, which will result in the lock to
be taken again, which will also go to the slow path because it queues
behind itself and so won't ever make progress.
An example trace of a deadlock:
__pv_queued_spin_lock_slowpath
trace_clock_global
ring_buffer_lock_reserve
trace_event_buffer_lock_reserve
trace_event_buffer_reserve
trace_event_raw_event_hcall_exit
__trace_hcall_exit
plpar_hcall_norets_trace
__pv_queued_spin_lock_slowpath
trace_clock_global
ring_buffer_lock_reserve
trace_event_buffer_lock_reserve
trace_event_buffer_reserve
trace_event_raw_event_rcu_dyntick
rcu_irq_exit
irq_exit
__do_irq
call_do_irq
do_IRQ
hardware_interrupt_common_virt
Fix this by introducing plpar_hcall_norets_notrace(), and using that to
make SPLPAR virtual processor dispatching hcalls by the paravirt
spinlock code.
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/hvcall.h | 3 +++
arch/powerpc/include/asm/paravirt.h | 22 +++++++++++++++++++---
arch/powerpc/platforms/pseries/hvCall.S | 10 ++++++++++
arch/powerpc/platforms/pseries/lpar.c | 3 +--
4 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index 443050906018..e3b29eda8074 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -448,6 +448,9 @@
*/
long plpar_hcall_norets(unsigned long opcode, ...);
+/* Variant which does not do hcall tracing */
+long plpar_hcall_norets_notrace(unsigned long opcode, ...);
+
/**
* plpar_hcall: - Make a pseries hypervisor call
* @opcode: The hypervisor call to make.
diff --git a/arch/powerpc/include/asm/paravirt.h b/arch/powerpc/include/asm/paravirt.h
index 5d1726bb28e7..bcb7b5f917be 100644
--- a/arch/powerpc/include/asm/paravirt.h
+++ b/arch/powerpc/include/asm/paravirt.h
@@ -28,19 +28,35 @@ static inline u32 yield_count_of(int cpu)
return be32_to_cpu(yield_count);
}
+/*
+ * Spinlock code confers and prods, so don't trace the hcalls because the
+ * tracing code takes spinlocks which can cause recursion deadlocks.
+ *
+ * These calls are made while the lock is not held: the lock slowpath yields if
+ * it can not acquire the lock, and unlock slow path might prod if a waiter has
+ * yielded). So this may not be a problem for simple spin locks because the
+ * tracing does not technically recurse on the lock, but we avoid it anyway.
+ *
+ * However the queued spin lock contended path is more strictly ordered: the
+ * H_CONFER hcall is made after the task has queued itself on the lock, so then
+ * recursing on that lock will cause the task to then queue up again behind the
+ * first instance (or worse: queued spinlocks use tricks that assume a context
+ * never waits on more than one spinlock, so such recursion may cause random
+ * corruption in the lock code).
+ */
static inline void yield_to_preempted(int cpu, u32 yield_count)
{
- plpar_hcall_norets(H_CONFER, get_hard_smp_processor_id(cpu), yield_count);
+ plpar_hcall_norets_notrace(H_CONFER, get_hard_smp_processor_id(cpu), yield_count);
}
static inline void prod_cpu(int cpu)
{
- plpar_hcall_norets(H_PROD, get_hard_smp_processor_id(cpu));
+ plpar_hcall_norets_notrace(H_PROD, get_hard_smp_processor_id(cpu));
}
static inline void yield_to_any(void)
{
- plpar_hcall_norets(H_CONFER, -1, 0);
+ plpar_hcall_norets_notrace(H_CONFER, -1, 0);
}
#else
static inline bool is_shared_processor(void)
diff --git a/arch/powerpc/platforms/pseries/hvCall.S b/arch/powerpc/platforms/pseries/hvCall.S
index 2136e42833af..8a2b8d64265b 100644
--- a/arch/powerpc/platforms/pseries/hvCall.S
+++ b/arch/powerpc/platforms/pseries/hvCall.S
@@ -102,6 +102,16 @@ END_FTR_SECTION(0, 1); \
#define HCALL_BRANCH(LABEL)
#endif
+_GLOBAL_TOC(plpar_hcall_norets_notrace)
+ HMT_MEDIUM
+
+ mfcr r0
+ stw r0,8(r1)
+ HVSC /* invoke the hypervisor */
+ lwz r0,8(r1)
+ mtcrf 0xff,r0
+ blr /* return r3 = status */
+
_GLOBAL_TOC(plpar_hcall_norets)
HMT_MEDIUM
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 1f3152ad7213..b619568a4d04 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -1830,8 +1830,7 @@ void hcall_tracepoint_unregfunc(void)
/*
* Since the tracing code might execute hcalls we need to guard against
- * recursion. One example of this are spinlocks calling H_YIELD on
- * shared processor partitions.
+ * recursion.
*/
static DEFINE_PER_CPU(unsigned int, hcall_trace_depth);
--
2.23.0
^ permalink raw reply related
* [PATCH v2 0/4] Fix queued spinlocks and a bit more
From: Nicholas Piggin @ 2021-05-08 10:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
This didn't seem to send properly, apologies if you get a duplicate.
Patch 1 is the important fix. 2 might fix something, although I haven't
provoked a crash yet.
Patch 3 is a small cleanup, and patch 4 I think is the right thing to do
but these could wait for later.
Since v1:
- Improved comments, changelogs, code style / wrapping.
Thanks,
Nick
Nicholas Piggin (4):
powerpc/pseries: Fix hcall tracing recursion in pv queued spinlocks
powerpc/pseries: Don't trace hcall tracing wrapper
powerpc/pseries: use notrace hcall variant for H_CEDE idle
powerpc/pseries: warn if recursing into the hcall tracing code
arch/powerpc/include/asm/hvcall.h | 3 +++
arch/powerpc/include/asm/paravirt.h | 22 ++++++++++++++---
arch/powerpc/include/asm/plpar_wrappers.h | 6 ++++-
arch/powerpc/platforms/pseries/hvCall.S | 10 ++++++++
arch/powerpc/platforms/pseries/lpar.c | 29 ++++++++++-------------
5 files changed, 49 insertions(+), 21 deletions(-)
--
2.23.0
^ permalink raw reply
* [PATCH v2 2/4] powerpc/pseries: Don't trace hcall tracing wrapper
From: Nicholas Piggin @ 2021-05-08 10:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Naveen N . Rao, Nicholas Piggin
In-Reply-To: <20210508101455.1578318-1-npiggin@gmail.com>
This doesn't seem very useful to trace before the recursion check, even
if the ftrace code has any recursion checks of its own. Be on the safe
side and don't trace the hcall trace wrappers.
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Reported-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/pseries/lpar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index b619568a4d04..d79d7410c320 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -1835,7 +1835,7 @@ void hcall_tracepoint_unregfunc(void)
static DEFINE_PER_CPU(unsigned int, hcall_trace_depth);
-void __trace_hcall_entry(unsigned long opcode, unsigned long *args)
+notrace void __trace_hcall_entry(unsigned long opcode, unsigned long *args)
{
unsigned long flags;
unsigned int *depth;
@@ -1863,7 +1863,7 @@ void __trace_hcall_entry(unsigned long opcode, unsigned long *args)
local_irq_restore(flags);
}
-void __trace_hcall_exit(long opcode, long retval, unsigned long *retbuf)
+notrace void __trace_hcall_exit(long opcode, long retval, unsigned long *retbuf)
{
unsigned long flags;
unsigned int *depth;
--
2.23.0
^ permalink raw reply related
* [PATCH v2 3/4] powerpc/pseries: use notrace hcall variant for H_CEDE idle
From: Nicholas Piggin @ 2021-05-08 10:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Naveen N . Rao, Nicholas Piggin
In-Reply-To: <20210508101455.1578318-1-npiggin@gmail.com>
Rather than special-case H_CEDE in the hcall trace wrappers, make the
idle H_CEDE call use plpar_hcall_norets_notrace().
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/plpar_wrappers.h | 6 +++++-
arch/powerpc/platforms/pseries/lpar.c | 10 ----------
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h b/arch/powerpc/include/asm/plpar_wrappers.h
index ece84a430701..83e0f701ebc6 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -28,7 +28,11 @@ static inline void set_cede_latency_hint(u8 latency_hint)
static inline long cede_processor(void)
{
- return plpar_hcall_norets(H_CEDE);
+ /*
+ * We cannot call tracepoints inside RCU idle regions which
+ * means we must not trace H_CEDE.
+ */
+ return plpar_hcall_norets_notrace(H_CEDE);
}
static inline long extended_cede_processor(unsigned long latency_hint)
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index d79d7410c320..ad1cec80019b 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -1840,13 +1840,6 @@ notrace void __trace_hcall_entry(unsigned long opcode, unsigned long *args)
unsigned long flags;
unsigned int *depth;
- /*
- * We cannot call tracepoints inside RCU idle regions which
- * means we must not trace H_CEDE.
- */
- if (opcode == H_CEDE)
- return;
-
local_irq_save(flags);
depth = this_cpu_ptr(&hcall_trace_depth);
@@ -1868,9 +1861,6 @@ notrace void __trace_hcall_exit(long opcode, long retval, unsigned long *retbuf)
unsigned long flags;
unsigned int *depth;
- if (opcode == H_CEDE)
- return;
-
local_irq_save(flags);
depth = this_cpu_ptr(&hcall_trace_depth);
--
2.23.0
^ permalink raw reply related
* [PATCH v2 4/4] powerpc/pseries: warn if recursing into the hcall tracing code
From: Nicholas Piggin @ 2021-05-08 10:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20210508101455.1578318-1-npiggin@gmail.com>
The hcall tracing code has a recursion check built in, which skips
tracing if we are already tracing an hcall.
However if the tracing code has problems with recursion, this check
may not catch all cases because the tracing code could be invoked from
a different tracepoint first, then make an hcall that gets traced,
then recurse.
Add an explicit warning if recursion is detected here, which might help
to notice tracing code making hcalls. Really the core trace code should
have its own recursion checking and warnings though.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/pseries/lpar.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index ad1cec80019b..dab356e3ff87 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -1829,8 +1829,14 @@ void hcall_tracepoint_unregfunc(void)
#endif
/*
- * Since the tracing code might execute hcalls we need to guard against
- * recursion.
+ * Keep track of hcall tracing depth and prevent recursion. Warn if any is
+ * detected because it may indicate a problem. This will not catch all
+ * problems with tracing code making hcalls, because the tracing might have
+ * been invoked from a non-hcall, so the first hcall could recurse into it
+ * without warning here, but this better than nothing.
+ *
+ * Hcalls with specific problems being traced should use the _notrace
+ * plpar_hcall variants.
*/
static DEFINE_PER_CPU(unsigned int, hcall_trace_depth);
@@ -1844,7 +1850,7 @@ notrace void __trace_hcall_entry(unsigned long opcode, unsigned long *args)
depth = this_cpu_ptr(&hcall_trace_depth);
- if (*depth)
+ if (WARN_ON_ONCE(*depth))
goto out;
(*depth)++;
@@ -1865,7 +1871,7 @@ notrace void __trace_hcall_exit(long opcode, long retval, unsigned long *retbuf)
depth = this_cpu_ptr(&hcall_trace_depth);
- if (*depth)
+ if (*depth) /* Don't warn again on the way out */
goto out;
(*depth)++;
--
2.23.0
^ permalink raw reply related
* Re: Kernel crosscompilers
From: Christophe Leroy @ 2021-05-08 10:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <CAK8P3a3V=y8tHkN6JSpA54bKAOZv9RK04WcVE9LPL0r-WE0Nmw@mail.gmail.com>
Le 08/05/2021 à 11:43, Arnd Bergmann a écrit :
> On Sat, May 8, 2021 at 8:46 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>> Something is going wrong with asm goto output. I implemented get_user() helpers with asm goto this
>> cycle (commit 5cd29b1fd3e8). I tested it with CLANG before submitting, it was working.
>
> BTW, can you point me to those patches? I think it would be nice if we
> could eventually
> converge parts of get_user()/put_user() implementation on something
> that works for all
> architectures, we do seem to rewrite these way too often. Ideally we'd
> have something
> in asm-generic that provides all the wrappers, and just requires an
> architecture to
> implement the inline asm helpers for each of the sizes.
>
The series that is merged for 5.13 is here:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=233250&state=*
And of course the result is just
https://github.com/linuxppc/linux/blob/master/arch/powerpc/include/asm/uaccess.h
and all its history at
https://github.com/linuxppc/linux/commits/master/arch/powerpc/include/asm/uaccess.h
The fix from today here:
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/cf0a050d124d4f426cdc7a74009d17b01d8d8969.1620465917.git.christophe.leroy@csgroup.eu/
I made a try to use asm-generic/uaccess.h a few weeks ago, but it was not conclusive. I can't
remember the details, but I can have a new look at it next week if you are interested with the details.
Christophe
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: imx-akcodec: Add imx-akcodec machine driver
From: Shengjiu Wang @ 2021-05-08 11:11 UTC (permalink / raw)
To: Marco Felsch
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
alsa-devel, Fabio Estevam, linux-kernel, Timur Tabi, Xiubo Li,
linuxppc-dev, Shengjiu Wang, Takashi Iwai, Liam Girdwood,
Nicolin Chen, Rob Herring, Mark Brown, Sascha Hauer, Shawn Guo,
Sascha Hauer,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
NXP Linux Team
In-Reply-To: <20210504065736.bcnatgmy2gczynsr@pengutronix.de>
Hi
On Tue, May 4, 2021 at 2:59 PM Marco Felsch <m.felsch@pengutronix.de> wrote:
>
> On 21-04-23 13:51, Shengjiu Wang wrote:
> > Add machine driver for i.MX boards that have
> > AK4458/AK5558/AK4497/AK5552 DAC/ADC attached to
> > SAI interface.
>
> Why? Does simple-audio-card don't fit?
No. We need to support asrc->sai->codec case,
but simple-audio-card don't support it. simple-audio-card
needs the cpu dai is dummy on BE. And we need to
support the DSD format, this driver help to switch
the dai fmt from pdm to i2s according to the DSD or non-DSD.
best regards
wang shengjiu
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: dt-bindings: imx-akcodec: Add binding doc for akcodec machine driver
From: Shengjiu Wang @ 2021-05-08 11:14 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
alsa-devel, Fabio Estevam, linux-kernel, Timur Tabi, Xiubo Li,
linuxppc-dev, Shengjiu Wang, Takashi Iwai, Liam Girdwood,
Nicolin Chen, Mark Brown, NXP Linux Team, Sascha Hauer, Shawn Guo,
Sascha Hauer,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20210503170030.GA1987906@robh.at.kernel.org>
Hi
On Tue, May 4, 2021 at 1:01 AM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, Apr 23, 2021 at 01:51:47PM +0800, Shengjiu Wang wrote:
> > Imx-akcodec is a new added machine driver for supporting
> > ak4458/ak5558/ak5552/ak4497 codec on i.MX platforms.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > ---
> > .../bindings/sound/imx-audio-akcodec.yaml | 60 +++++++++++++++++++
> > 1 file changed, 60 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-akcodec.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/sound/imx-audio-akcodec.yaml b/Documentation/devicetree/bindings/sound/imx-audio-akcodec.yaml
> > new file mode 100644
> > index 000000000000..7419bf7224e9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/sound/imx-audio-akcodec.yaml
> > @@ -0,0 +1,60 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/sound/imx-audio-akcodec.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NXP i.MX audio complex with AK4458/AK5558/AK5552/AK4497 codec
>
> Looks like the existing fsl-asoc-card.txt? You should convert to schema
> and use that. Otherwise, my comments are based on this all being 'new'.
Ok, let's treat it as 'new'
>
> > +
> > +maintainers:
> > + - Shengjiu Wang <shengjiu.wang@nxp.com>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - fsl,imx8mq-audio-ak4458
> > + - fsl,imx8mq-audio-ak4497
> > + - fsl,imx8mq-audio-ak5558
> > + - fsl,imx-audio-ak4497
> > + - fsl,imx-audio-ak4458
> > + - fsl,imx-audio-ak5558
> > + - fsl,imx-audio-ak5552
>
> I continue to not understand why audio bindings need the codec(s) in the
> compatible strings. Can't you look up the codec thru the audio-codec
> property?
I will try to remove the codecs type from the compatible string and check
the codec type in driver.
>
> > +
> > + model:
> > + $ref: /schemas/types.yaml#/definitions/string
> > + description: User specified audio sound card name
> > +
> > + audio-cpu:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description: The phandle of a CPU DAI controller
> > +
> > + audio-codec:
> > + description: The phandle of Codec DAI controllers, there are two
> > + controllers maximum.
>
> We have the common 'sound-dai' property. See the simple-card.yaml
> binding.
ok, will use sound-dai.
>
> > +
> > + audio-asrc:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description: The phandle of ASRC. It can be absent if there's no
> > + need to add ASRC support via DPCM.
>
> Needs a vendor prefix.
ok, can be removed in the next version.
>
> > +
> > + fsl,tdm:
> > + $ref: /schemas/types.yaml#/definitions/flag
> > + description: |
> > + This is a boolean property. If present, the TDM mode is enabled.
>
> But this one seems like something that could or should be common.
Ok, I will use the common one in the next version.
>
> > +
> > +required:
> > + - compatible
> > + - model
> > + - audio-cpu
> > + - audio-codec
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + sound-ak4458 {
> > + compatible = "fsl,imx-audio-ak4458";
> > + model = "ak4458-audio";
> > + audio-cpu = <&sai1>;
> > + audio-codec = <&ak4458_1>, <&ak4458_2>;
> > + };
> > --
> > 2.17.1
> >
^ 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