* [PATCH v2] powerpc/mce: Fix access error in mce handler
From: Ganesh Goudar @ 2021-09-09 6:43 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: Ganesh Goudar, mahesh, npiggin
We queue an irq work for deferred processing of mce event
in realmode mce handler, where translation is disabled.
Queuing of the work may result in accessing memory outside
RMO region, such access needs the translation to be enabled
for an LPAR running with hash mmu else the kernel crashes.
After enabling translation in mce_handle_error() we used to
leave it enabled to avoid crashing here, but now with the
commit 74c3354bc1d89 ("powerpc/pseries/mce: restore msr before
returning from handler") we are restoring the MSR to disable
translation.
Hence to fix this enable the translation before queuing the work.
Without this change following trace is seen on injecting SLB
multihit in an LPAR running with hash mmu.
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
CPU: 5 PID: 1883 Comm: insmod Tainted: G OE 5.14.0-mce+ #137
NIP: c000000000735d60 LR: c000000000318640 CTR: 0000000000000000
REGS: c00000001ebff9a0 TRAP: 0300 Tainted: G OE (5.14.0-mce+)
MSR: 8000000000001003 <SF,ME,RI,LE> CR: 28008228 XER: 00000001
CFAR: c00000000031863c DAR: c00000027fa8fe08 DSISR: 40000000 IRQMASK: 0
GPR00: c0000000003186d0 c00000001ebffc40 c000000001b0df00 c0000000016337e8
GPR04: c0000000016337e8 c00000027fa8fe08 0000000000000023 c0000000016337f0
GPR08: 0000000000000023 c0000000012ffe08 0000000000000000 c008000001460240
GPR12: 0000000000000000 c00000001ec9a900 c00000002ac4bd00 0000000000000000
GPR16: 00000000000005a0 c0080000006b0000 c0080000006b05a0 c000000000ff3068
GPR20: c00000002ac4bbc0 0000000000000001 c00000002ac4bbc0 c008000001490298
GPR24: c008000001490108 c000000001636198 c008000001470090 c008000001470058
GPR28: 0000000000000510 c008000001000000 c008000008000019 0000000000000019
NIP [c000000000735d60] llist_add_batch+0x0/0x40
LR [c000000000318640] __irq_work_queue_local+0x70/0xc0
Call Trace:
[c00000001ebffc40] [c00000001ebffc0c] 0xc00000001ebffc0c (unreliable)
[c00000001ebffc60] [c0000000003186d0] irq_work_queue+0x40/0x70
[c00000001ebffc80] [c00000000004425c] machine_check_queue_event+0xbc/0xd0
[c00000001ebffcf0] [c00000000000838c] machine_check_early_common+0x16c/0x1f4
Fixes: 74c3354bc1d89 ("powerpc/pseries/mce: restore msr before returning from handler")
Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
---
v2: Change in commit message.
---
arch/powerpc/kernel/mce.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index 47a683cd00d2..9d1e39d42e3e 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -249,6 +249,7 @@ void machine_check_queue_event(void)
{
int index;
struct machine_check_event evt;
+ unsigned long msr;
if (!get_mce_event(&evt, MCE_EVENT_RELEASE))
return;
@@ -262,8 +263,19 @@ void machine_check_queue_event(void)
memcpy(&local_paca->mce_info->mce_event_queue[index],
&evt, sizeof(evt));
- /* Queue irq work to process this event later. */
- irq_work_queue(&mce_event_process_work);
+ /* Queue irq work to process this event later. Before
+ * queuing the work enable translation for non radix LPAR,
+ * as irq_work_queue may try to access memory outside RMO
+ * region.
+ */
+ if (!radix_enabled() && firmware_has_feature(FW_FEATURE_LPAR)) {
+ msr = mfmsr();
+ mtmsr(msr | MSR_IR | MSR_DR);
+ irq_work_queue(&mce_event_process_work);
+ mtmsr(msr);
+ } else {
+ irq_work_queue(&mce_event_process_work);
+ }
}
void mce_common_process_ue(struct pt_regs *regs,
--
2.31.1
^ permalink raw reply related
* Re: [PATCH v3 8/8] treewide: Replace the use of mem_encrypt_active() with cc_platform_has()
From: Christophe Leroy @ 2021-09-09 7:25 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, Brijesh Singh, David Airlie,
Dave Hansen, Paul Mackerras, Will Deacon, Andi Kleen, Baoquan He,
Christian Borntraeger, Joerg Roedel, Christoph Hellwig,
Peter Zijlstra, Ingo Molnar, Dave Young, Tianyu Lan,
Daniel Vetter, Vasily Gorbik, Heiko Carstens, Maarten Lankhorst,
Maxime Ripard, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
Thomas Zimmermann
In-Reply-To: <46a18427dc4e9dda985b10e472965e3e4c769f1d.1631141919.git.thomas.lendacky@amd.com>
On 9/8/21 10:58 PM, Tom Lendacky wrote:
>
> diff --git a/arch/powerpc/include/asm/mem_encrypt.h b/arch/powerpc/include/asm/mem_encrypt.h
> index ba9dab07c1be..2f26b8fc8d29 100644
> --- a/arch/powerpc/include/asm/mem_encrypt.h
> +++ b/arch/powerpc/include/asm/mem_encrypt.h
> @@ -10,11 +10,6 @@
>
> #include <asm/svm.h>
>
> -static inline bool mem_encrypt_active(void)
> -{
> - return is_secure_guest();
> -}
> -
> static inline bool force_dma_unencrypted(struct device *dev)
> {
> return is_secure_guest();
> diff --git a/arch/powerpc/platforms/pseries/svm.c b/arch/powerpc/platforms/pseries/svm.c
> index 87f001b4c4e4..c083ecbbae4d 100644
> --- a/arch/powerpc/platforms/pseries/svm.c
> +++ b/arch/powerpc/platforms/pseries/svm.c
> @@ -8,6 +8,7 @@
>
> #include <linux/mm.h>
> #include <linux/memblock.h>
> +#include <linux/cc_platform.h>
> #include <asm/machdep.h>
> #include <asm/svm.h>
> #include <asm/swiotlb.h>
> @@ -63,7 +64,7 @@ void __init svm_swiotlb_init(void)
>
> int set_memory_encrypted(unsigned long addr, int numpages)
> {
> - if (!mem_encrypt_active())
> + if (!cc_platform_has(CC_ATTR_MEM_ENCRYPT))
> return 0;
>
> if (!PAGE_ALIGNED(addr))
> @@ -76,7 +77,7 @@ int set_memory_encrypted(unsigned long addr, int numpages)
>
> int set_memory_decrypted(unsigned long addr, int numpages)
> {
> - if (!mem_encrypt_active())
> + if (!cc_platform_has(CC_ATTR_MEM_ENCRYPT))
> return 0;
>
> if (!PAGE_ALIGNED(addr))
This change unnecessarily complexifies the two functions. This is due to
cc_platform_has() being out-line. It should really remain inline.
Before the change we got:
0000000000000000 <.set_memory_encrypted>:
0: 7d 20 00 a6 mfmsr r9
4: 75 29 00 40 andis. r9,r9,64
8: 41 82 00 48 beq 50 <.set_memory_encrypted+0x50>
c: 78 69 04 20 clrldi r9,r3,48
10: 2c 29 00 00 cmpdi r9,0
14: 40 82 00 4c bne 60 <.set_memory_encrypted+0x60>
18: 7c 08 02 a6 mflr r0
1c: 7c 85 23 78 mr r5,r4
20: 78 64 85 02 rldicl r4,r3,48,20
24: 61 23 f1 34 ori r3,r9,61748
28: f8 01 00 10 std r0,16(r1)
2c: f8 21 ff 91 stdu r1,-112(r1)
30: 48 00 00 01 bl 30 <.set_memory_encrypted+0x30>
30: R_PPC64_REL24 .ucall_norets
34: 60 00 00 00 nop
38: 38 60 00 00 li r3,0
3c: 38 21 00 70 addi r1,r1,112
40: e8 01 00 10 ld r0,16(r1)
44: 7c 08 03 a6 mtlr r0
48: 4e 80 00 20 blr
50: 38 60 00 00 li r3,0
54: 4e 80 00 20 blr
60: 38 60 ff ea li r3,-22
64: 4e 80 00 20 blr
After the change we get:
0000000000000000 <.set_memory_encrypted>:
0: 7c 08 02 a6 mflr r0
4: fb c1 ff f0 std r30,-16(r1)
8: fb e1 ff f8 std r31,-8(r1)
c: 7c 7f 1b 78 mr r31,r3
10: 38 60 00 00 li r3,0
14: 7c 9e 23 78 mr r30,r4
18: f8 01 00 10 std r0,16(r1)
1c: f8 21 ff 81 stdu r1,-128(r1)
20: 48 00 00 01 bl 20 <.set_memory_encrypted+0x20>
20: R_PPC64_REL24 .cc_platform_has
24: 60 00 00 00 nop
28: 2c 23 00 00 cmpdi r3,0
2c: 41 82 00 44 beq 70 <.set_memory_encrypted+0x70>
30: 7b e9 04 20 clrldi r9,r31,48
34: 2c 29 00 00 cmpdi r9,0
38: 40 82 00 58 bne 90 <.set_memory_encrypted+0x90>
3c: 38 60 00 00 li r3,0
40: 7f c5 f3 78 mr r5,r30
44: 7b e4 85 02 rldicl r4,r31,48,20
48: 60 63 f1 34 ori r3,r3,61748
4c: 48 00 00 01 bl 4c <.set_memory_encrypted+0x4c>
4c: R_PPC64_REL24 .ucall_norets
50: 60 00 00 00 nop
54: 38 60 00 00 li r3,0
58: 38 21 00 80 addi r1,r1,128
5c: e8 01 00 10 ld r0,16(r1)
60: eb c1 ff f0 ld r30,-16(r1)
64: eb e1 ff f8 ld r31,-8(r1)
68: 7c 08 03 a6 mtlr r0
6c: 4e 80 00 20 blr
70: 38 21 00 80 addi r1,r1,128
74: 38 60 00 00 li r3,0
78: e8 01 00 10 ld r0,16(r1)
7c: eb c1 ff f0 ld r30,-16(r1)
80: eb e1 ff f8 ld r31,-8(r1)
84: 7c 08 03 a6 mtlr r0
88: 4e 80 00 20 blr
90: 38 60 ff ea li r3,-22
94: 4b ff ff c4 b 58 <.set_memory_encrypted+0x58>
^ permalink raw reply
* Re: [PATCH v3 0/8] Implement generic cc_platform_has() helper function
From: Christian Borntraeger @ 2021-09-09 7:32 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, Brijesh Singh, David Airlie,
Dave Hansen, Paul Mackerras, Will Deacon, Ard Biesheuvel,
Andi Kleen, Baoquan He, Joerg Roedel, Christoph Hellwig,
Peter Zijlstra, Ingo Molnar, Dave Young, Tianyu Lan,
Thomas Zimmermann, Vasily Gorbik, Heiko Carstens,
Maarten Lankhorst, Maxime Ripard, Borislav Petkov,
Andy Lutomirski, Thomas Gleixner, Daniel Vetter
In-Reply-To: <cover.1631141919.git.thomas.lendacky@amd.com>
On 09.09.21 00:58, Tom Lendacky wrote:
> This patch series provides a generic helper function, cc_platform_has(),
> to replace the sme_active(), sev_active(), sev_es_active() and
> mem_encrypt_active() functions.
>
> It is expected that as new confidential computing technologies are
> added to the kernel, they can all be covered by a single function call
> instead of a collection of specific function calls all called from the
> same locations.
>
> The powerpc and s390 patches have been compile tested only. Can the
> folks copied on this series verify that nothing breaks for them.
Is there a tree somewhere?
Also,
> a new file, arch/powerpc/platforms/pseries/cc_platform.c, has been
> created for powerpc to hold the out of line function.
>
> Cc: Andi Kleen <ak@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Heiko Carstens <hca@linux.ibm.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Vasily Gorbik <gor@linux.ibm.com>
> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Christoph Hellwig <hch@infradead.org>
>
> ---
>
> Patches based on:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> 4b93c544e90e ("thunderbolt: test: split up test cases in tb_test_credit_alloc_all")
>
> Changes since v2:
> - Changed the name from prot_guest_has() to cc_platform_has()
> - Took the cc_platform_has() function out of line. Created two new files,
> cc_platform.c, in both x86 and ppc to implment the function. As a
> result, also changed the attribute defines into enums.
> - Removed any received Reviewed-by's and Acked-by's given changes in this
> version.
> - Added removal of new instances of mem_encrypt_active() usage in powerpc
> arch.
> - Based on latest Linux tree to pick up powerpc changes related to the
> mem_encrypt_active() function.
>
> Changes since v1:
> - Moved some arch ioremap functions within #ifdef CONFIG_AMD_MEM_ENCRYPT
> in prep for use of prot_guest_has() by TDX.
> - Added type includes to the the protected_guest.h header file to prevent
> build errors outside of x86.
> - Made amd_prot_guest_has() EXPORT_SYMBOL_GPL
> - Used amd_prot_guest_has() in place of checking sme_me_mask in the
> arch/x86/mm/mem_encrypt.c file.
>
> Tom Lendacky (8):
> x86/ioremap: Selectively build arch override encryption functions
> mm: Introduce a function to check for confidential computing features
> x86/sev: Add an x86 version of cc_platform_has()
> powerpc/pseries/svm: Add a powerpc version of cc_platform_has()
> x86/sme: Replace occurrences of sme_active() with cc_platform_has()
> x86/sev: Replace occurrences of sev_active() with cc_platform_has()
> x86/sev: Replace occurrences of sev_es_active() with cc_platform_has()
> treewide: Replace the use of mem_encrypt_active() with
> cc_platform_has()
>
> arch/Kconfig | 3 +
> arch/powerpc/include/asm/mem_encrypt.h | 5 --
> arch/powerpc/platforms/pseries/Kconfig | 1 +
> arch/powerpc/platforms/pseries/Makefile | 2 +
> arch/powerpc/platforms/pseries/cc_platform.c | 26 ++++++
> arch/powerpc/platforms/pseries/svm.c | 5 +-
> arch/s390/include/asm/mem_encrypt.h | 2 -
> arch/x86/Kconfig | 1 +
> arch/x86/include/asm/io.h | 8 ++
> arch/x86/include/asm/kexec.h | 2 +-
> arch/x86/include/asm/mem_encrypt.h | 14 +---
> arch/x86/kernel/Makefile | 3 +
> arch/x86/kernel/cc_platform.c | 21 +++++
> arch/x86/kernel/crash_dump_64.c | 4 +-
> arch/x86/kernel/head64.c | 4 +-
> arch/x86/kernel/kvm.c | 3 +-
> arch/x86/kernel/kvmclock.c | 4 +-
> arch/x86/kernel/machine_kexec_64.c | 19 +++--
> arch/x86/kernel/pci-swiotlb.c | 9 +-
> arch/x86/kernel/relocate_kernel_64.S | 2 +-
> arch/x86/kernel/sev.c | 6 +-
> arch/x86/kvm/svm/svm.c | 3 +-
> arch/x86/mm/ioremap.c | 18 ++--
> arch/x86/mm/mem_encrypt.c | 57 +++++++------
> arch/x86/mm/mem_encrypt_identity.c | 3 +-
> arch/x86/mm/pat/set_memory.c | 3 +-
> arch/x86/platform/efi/efi_64.c | 9 +-
> arch/x86/realmode/init.c | 8 +-
> 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/init.c | 7 +-
> drivers/iommu/amd/iommu.c | 3 +-
> drivers/iommu/amd/iommu_v2.c | 3 +-
> drivers/iommu/iommu.c | 3 +-
> fs/proc/vmcore.c | 6 +-
> include/linux/cc_platform.h | 88 ++++++++++++++++++++
> include/linux/mem_encrypt.h | 4 -
> kernel/dma/swiotlb.c | 4 +-
> 40 files changed, 267 insertions(+), 114 deletions(-)
> create mode 100644 arch/powerpc/platforms/pseries/cc_platform.c
> create mode 100644 arch/x86/kernel/cc_platform.c
> create mode 100644 include/linux/cc_platform.h
>
>
> base-commit: 4b93c544e90e2b28326182d31ee008eb80e02074
>
^ permalink raw reply
* Re: [PATCH v3 2/8] mm: Introduce a function to check for confidential computing features
From: Christophe Leroy @ 2021-09-09 7:35 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, Joerg Roedel,
Christoph Hellwig, Borislav Petkov, Brijesh Singh
In-Reply-To: <0a7618d54e7e954ee56c22ad1b94af2ffe69543a.1631141919.git.thomas.lendacky@amd.com>
On 9/8/21 10:58 PM, Tom Lendacky wrote:
> In prep for other confidential computing technologies, introduce a generic
> helper function, cc_platform_has(), that can be used to check for specific
I have little problem with that naming.
For me CC has always meant Compiler Collection.
> active confidential computing 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>
> ---
> arch/Kconfig | 3 ++
> include/linux/cc_platform.h | 88 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 91 insertions(+)
> create mode 100644 include/linux/cc_platform.h
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 3743174da870..ca7c359e5da8 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -1234,6 +1234,9 @@ config RELR
> config ARCH_HAS_MEM_ENCRYPT
> bool
>
> +config ARCH_HAS_CC_PLATFORM
> + bool
> +
> config HAVE_SPARSE_SYSCALL_NR
> bool
> help
> diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
> new file mode 100644
> index 000000000000..253f3ea66cd8
> --- /dev/null
> +++ b/include/linux/cc_platform.h
> @@ -0,0 +1,88 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Confidential Computing Platform Capability checks
> + *
> + * Copyright (C) 2021 Advanced Micro Devices, Inc.
> + *
> + * Author: Tom Lendacky <thomas.lendacky@amd.com>
> + */
> +
> +#ifndef _CC_PLATFORM_H
> +#define _CC_PLATFORM_H
> +
> +#include <linux/types.h>
> +#include <linux/stddef.h>
> +
> +/**
> + * enum cc_attr - Confidential computing attributes
> + *
> + * These attributes represent confidential computing features that are
> + * currently active.
> + */
> +enum cc_attr {
> + /**
> + * @CC_ATTR_MEM_ENCRYPT: Memory encryption is active
> + *
> + * The platform/OS is running with active memory encryption. This
> + * includes running either as a bare-metal system or a hypervisor
> + * and actively using memory encryption or as a guest/virtual machine
> + * and actively using memory encryption.
> + *
> + * Examples include SME, SEV and SEV-ES.
> + */
> + CC_ATTR_MEM_ENCRYPT,
> +
> + /**
> + * @CC_ATTR_HOST_MEM_ENCRYPT: Host memory encryption is active
> + *
> + * The platform/OS is running as a bare-metal system or a hypervisor
> + * and actively using memory encryption.
> + *
> + * Examples include SME.
> + */
> + CC_ATTR_HOST_MEM_ENCRYPT,
> +
> + /**
> + * @CC_ATTR_GUEST_MEM_ENCRYPT: Guest memory encryption is active
> + *
> + * The platform/OS is running as a guest/virtual machine and actively
> + * using memory encryption.
> + *
> + * Examples include SEV and SEV-ES.
> + */
> + CC_ATTR_GUEST_MEM_ENCRYPT,
> +
> + /**
> + * @CC_ATTR_GUEST_STATE_ENCRYPT: Guest state encryption is active
> + *
> + * The platform/OS is running as a guest/virtual machine and actively
> + * using memory encryption and register state encryption.
> + *
> + * Examples include SEV-ES.
> + */
> + CC_ATTR_GUEST_STATE_ENCRYPT,
> +};
> +
> +#ifdef CONFIG_ARCH_HAS_CC_PLATFORM
> +
> +/**
> + * cc_platform_has() - Checks if the specified cc_attr attribute is active
> + * @attr: Confidential computing attribute to check
> + *
> + * The cc_platform_has() function will return an indicator as to whether the
> + * specified Confidential Computing attribute is currently active.
> + *
> + * Context: Any context
> + * Return:
> + * * TRUE - Specified Confidential Computing attribute is active
> + * * FALSE - Specified Confidential Computing attribute is not active
> + */
> +bool cc_platform_has(enum cc_attr attr);
This declaration make it impossible for architectures to define this
function inline.
For such function, having it inline would make more sense as it would
allow GCC to perform constant folding and avoid the overhead of calling
a sub-function.
> +
> +#else /* !CONFIG_ARCH_HAS_CC_PLATFORM */
> +
> +static inline bool cc_platform_has(enum cc_attr attr) { return false; }
> +
> +#endif /* CONFIG_ARCH_HAS_CC_PLATFORM */
> +
> +#endif /* _CC_PLATFORM_H */
>
^ permalink raw reply
* Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()
From: Christophe Leroy @ 2021-09-09 7:40 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, Joerg Roedel,
Christoph Hellwig, Borislav Petkov, Brijesh Singh, Paul Mackerras
In-Reply-To: <9d4fc3f8ea7b325aaa1879beab1286876f45d450.1631141919.git.thomas.lendacky@amd.com>
On 9/8/21 10:58 PM, Tom Lendacky wrote:
> Introduce a powerpc version of the cc_platform_has() function. This will
> be used to replace the powerpc mem_encrypt_active() implementation, so
> the implementation will initially only support the CC_ATTR_MEM_ENCRYPT
> attribute.
>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/powerpc/platforms/pseries/Kconfig | 1 +
> arch/powerpc/platforms/pseries/Makefile | 2 ++
> arch/powerpc/platforms/pseries/cc_platform.c | 26 ++++++++++++++++++++
> 3 files changed, 29 insertions(+)
> create mode 100644 arch/powerpc/platforms/pseries/cc_platform.c
>
> diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
> index 5e037df2a3a1..2e57391e0778 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -159,6 +159,7 @@ config PPC_SVM
> select SWIOTLB
> select ARCH_HAS_MEM_ENCRYPT
> select ARCH_HAS_FORCE_DMA_UNENCRYPTED
> + select ARCH_HAS_CC_PLATFORM
> help
> There are certain POWER platforms which support secure guests using
> the Protected Execution Facility, with the help of an Ultravisor
> diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
> index 4cda0ef87be0..41d8aee98da4 100644
> --- a/arch/powerpc/platforms/pseries/Makefile
> +++ b/arch/powerpc/platforms/pseries/Makefile
> @@ -31,3 +31,5 @@ obj-$(CONFIG_FA_DUMP) += rtas-fadump.o
>
> obj-$(CONFIG_SUSPEND) += suspend.o
> obj-$(CONFIG_PPC_VAS) += vas.o
> +
> +obj-$(CONFIG_ARCH_HAS_CC_PLATFORM) += cc_platform.o
> diff --git a/arch/powerpc/platforms/pseries/cc_platform.c b/arch/powerpc/platforms/pseries/cc_platform.c
> new file mode 100644
> index 000000000000..e8021af83a19
> --- /dev/null
> +++ b/arch/powerpc/platforms/pseries/cc_platform.c
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Confidential Computing Platform Capability checks
> + *
> + * Copyright (C) 2021 Advanced Micro Devices, Inc.
> + *
> + * Author: Tom Lendacky <thomas.lendacky@amd.com>
> + */
> +
> +#include <linux/export.h>
> +#include <linux/cc_platform.h>
> +
> +#include <asm/machdep.h>
> +#include <asm/svm.h>
> +
> +bool cc_platform_has(enum cc_attr attr)
> +{
Please keep this function inline as mem_encrypt_active() is
> + switch (attr) {
> + case CC_ATTR_MEM_ENCRYPT:
> + return is_secure_guest();
> +
> + default:
> + return false;
> + }
> +}
> +EXPORT_SYMBOL_GPL(cc_platform_has);
>
^ permalink raw reply
* Re: [RESEND PATCH v4 1/4] drivers/nvdimm: Add nvdimm pmu structure
From: kajoljain @ 2021-09-09 7:55 UTC (permalink / raw)
To: Dan Williams
Cc: Linux NVDIMM, Santosh Sivaraj, maddy, Weiny, Ira, rnsastry,
Peter Zijlstra, Linux Kernel Mailing List, atrajeev,
Aneesh Kumar K.V, Vishal L Verma, Vaibhav Jain, Thomas Gleixner,
linuxppc-dev
In-Reply-To: <CAPcyv4jSL2cDxGiXEtyyce3eNEE_QUnnMjuLXb3iCwO8_7a7LQ@mail.gmail.com>
On 9/8/21 3:29 AM, Dan Williams wrote:
> Hi Kajol,
>
> Apologies for the delay in responding to this series, some comments below:
Hi Dan,
No issues, thanks for reviewing the patches.
>
> On Thu, Sep 2, 2021 at 10:10 PM Kajol Jain <kjain@linux.ibm.com> wrote:
>>
>> A structure is added, called nvdimm_pmu, for performance
>> stats reporting support of nvdimm devices. It can be used to add
>> nvdimm pmu data such as supported events and pmu event functions
>> like event_init/add/read/del with cpu hotplug support.
>>
>> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>> Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
>> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
>> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
>> ---
>> include/linux/nd.h | 43 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 43 insertions(+)
>>
>> diff --git a/include/linux/nd.h b/include/linux/nd.h
>> index ee9ad76afbba..712499cf7335 100644
>> --- a/include/linux/nd.h
>> +++ b/include/linux/nd.h
>> @@ -8,6 +8,8 @@
>> #include <linux/ndctl.h>
>> #include <linux/device.h>
>> #include <linux/badblocks.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/perf_event.h>
>>
>> enum nvdimm_event {
>> NVDIMM_REVALIDATE_POISON,
>> @@ -23,6 +25,47 @@ enum nvdimm_claim_class {
>> NVDIMM_CCLASS_UNKNOWN,
>> };
>>
>> +/* Event attribute array index */
>> +#define NVDIMM_PMU_FORMAT_ATTR 0
>> +#define NVDIMM_PMU_EVENT_ATTR 1
>> +#define NVDIMM_PMU_CPUMASK_ATTR 2
>> +#define NVDIMM_PMU_NULL_ATTR 3
>> +
>> +/**
>> + * struct nvdimm_pmu - data structure for nvdimm perf driver
>> + *
>> + * @name: name of the nvdimm pmu device.
>> + * @pmu: pmu data structure for nvdimm performance stats.
>> + * @dev: nvdimm device pointer.
>> + * @functions(event_init/add/del/read): platform specific pmu functions.
>
> This is not valid kernel-doc:
>
> include/linux/nd.h:67: warning: Function parameter or member
> 'event_init' not described in 'nvdimm_pmu'
> include/linux/nd.h:67: warning: Function parameter or member 'add' not
> described in 'nvdimm_pmu'
> include/linux/nd.h:67: warning: Function parameter or member 'del' not
> described in 'nvdimm_pmu'
> include/linux/nd.h:67: warning: Function parameter or member 'read'
> not described in 'nvdimm_pmu'
>
> ...but I think rather than fixing those up 'struct nvdimm_pmu' should be pruned.
>
> It's not clear to me that it is worth the effort to describe these
> details to the nvdimm core which is just going to turn around and call
> the pmu core. I'd just as soon have the driver call the pmu core
> directly, optionally passing in attributes and callbacks that come
> from the nvdimm core and/or the nvdimm provider.
The intend for adding these callbacks(event_init/add/del/read) is to give
flexibility to the nvdimm core to add some common checks/routines if required
in the future. Those checks can be common for all architecture with still having the
ability to call arch/platform specific driver code to use its own routines.
But as you said, currently we don't have any common checks and it directly
calling platform specific code, so we can get rid of it.
Should we remove this part for now?
>
> Otherwise it's also not clear which of these structure members are
> used at runtime vs purely used as temporary storage to pass parameters
> to the pmu core.
>
>> + * @attr_groups: data structure for events, formats and cpumask
>> + * @cpu: designated cpu for counter access.
>> + * @node: node for cpu hotplug notifier link.
>> + * @cpuhp_state: state for cpu hotplug notification.
>> + * @arch_cpumask: cpumask to get designated cpu for counter access.
>> + */
>> +struct nvdimm_pmu {
>> + const char *name;
>> + struct pmu pmu;
>> + struct device *dev;
>> + int (*event_init)(struct perf_event *event);
>> + int (*add)(struct perf_event *event, int flags);
>> + void (*del)(struct perf_event *event, int flags);
>> + void (*read)(struct perf_event *event);
>> + /*
>> + * Attribute groups for the nvdimm pmu. Index 0 used for
>> + * format attribute, index 1 used for event attribute,
>> + * index 2 used for cpusmask attribute and index 3 kept as NULL.
>> + */
>> + const struct attribute_group *attr_groups[4];
>
> Following from above, I'd rather this was organized as static
> attributes with an is_visible() helper for the groups for any dynamic
> aspects. That mirrors the behavior of nvdimm_create() and allows for
> device drivers to compose the attribute groups from a core set and /
> or a provider specific set.
Since we don't have any common events right now, Can I use papr
attributes directly or should we create dummy events for common thing and
then merged it with papr event list.
Thanks,
Kajol Jain
>
>> + int cpu;
>> + struct hlist_node node;
>> + enum cpuhp_state cpuhp_state;
>> +
>> + /* cpumask provided by arch/platform specific code */
>> + struct cpumask arch_cpumask;
>> +};
>> +
>> struct nd_device_driver {
>> struct device_driver drv;
>> unsigned long type;
>> --
>> 2.26.2
>>
^ permalink raw reply
* Re: [RESEND PATCH v4 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries
From: kajoljain @ 2021-09-09 8:03 UTC (permalink / raw)
To: Dan Williams
Cc: Linux NVDIMM, Santosh Sivaraj, maddy, Weiny, Ira, rnsastry,
Peter Zijlstra, Linux Kernel Mailing List, atrajeev,
Aneesh Kumar K.V, Vishal L Verma, Vaibhav Jain, Thomas Gleixner,
linuxppc-dev
In-Reply-To: <CAPcyv4h-MgZmteMSUfdeQL+XCxL5HvxK87HA3JYB0OoQUaPipQ@mail.gmail.com>
On 9/8/21 6:33 AM, Dan Williams wrote:
> On Thu, Sep 2, 2021 at 10:11 PM Kajol Jain <kjain@linux.ibm.com> wrote:
>>
>> Details is added for the event, cpumask and format attributes
>> in the ABI documentation.
>>
>> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>> Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
>> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
>> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
>> ---
>> Documentation/ABI/testing/sysfs-bus-papr-pmem | 31 +++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
>> index 95254cec92bf..4d86252448f8 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
>> +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
>> @@ -61,3 +61,34 @@ Description:
>> * "CchRHCnt" : Cache Read Hit Count
>> * "CchWHCnt" : Cache Write Hit Count
>> * "FastWCnt" : Fast Write Count
>> +
>> +What: /sys/devices/nmemX/format
>> +Date: June 2021
>> +Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
>> +Description: (RO) Attribute group to describe the magic bits
>> + that go into perf_event_attr.config for a particular pmu.
>> + (See ABI/testing/sysfs-bus-event_source-devices-format).
>> +
>> + Each attribute under this group defines a bit range of the
>> + perf_event_attr.config. Supported attribute is listed
>> + below::
>> +
>> + event = "config:0-4" - event ID
>> +
>> + For example::
>> + noopstat = "event=0x1"
>> +
>> +What: /sys/devices/nmemX/events
>
> That's not a valid sysfs path. Did you mean /sys/bus/nd/devices/nmemX?
Hi Dan,
Thanks, I will correct it and update it to `/sys/bus/event_source/devices/`
where perf creates sysfs files for given pmu.
>
>> +Date: June 2021
>> +Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
>> +Description: (RO) Attribute group to describe performance monitoring
>> + events specific to papr-scm. Each attribute in this group describes
>> + a single performance monitoring event supported by this nvdimm pmu.
>> + The name of the file is the name of the event.
>> + (See ABI/testing/sysfs-bus-event_source-devices-events).
>
> Given these events are in the generic namespace the ABI documentation
> should be generic as well. So I think move these entries to
> Documentation/ABI/testing/sysfs-bus-nvdimm directly.
>
> You can still mention papr-scm, but I would expect something like:
>
> What: /sys/bus/nd/devices/nmemX/events
> Date: September 2021
> KernelVersion: 5.16
> Contact: Kajol Jain <kjain@linux.ibm.com>
> Description:
> (RO) Attribute group to describe performance monitoring events
> for the nvdimm memory device. Each attribute in this group
> describes a single performance monitoring event supported by
> this nvdimm pmu. The name of the file is the name of the event.
> (See ABI/testing/sysfs-bus-event_source-devices-events). A
> listing of the events supported by a given nvdimm provider type
> can be found in Documentation/driver-api/nvdimm/$provider, for
> example: Documentation/driver-api/nvdimm/papr-scm.
>
>
I will update it accordingly.
>
>> +
>> +What: /sys/devices/nmemX/cpumask
>> +Date: June 2021
>> +Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
>> +Description: (RO) This sysfs file exposes the cpumask which is designated to make
>> + HCALLs to retrieve nvdimm pmu event counter data.
>
> Seems this one would be provider generic, so no need to refer to PPC
> specific concepts like HCALLs.
>
Sure will update it.
Thanks,
Kajol Jain
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: Change value of MAX_TAIL_CALL_CNT from 32 to 33
From: Daniel Borkmann @ 2021-09-09 7:57 UTC (permalink / raw)
To: Andrii Nakryiko, Tiezhu Yang
Cc: Song Liu, Catalin Marinas, Zi Shen Lim, Alexei Starovoitov,
Russell King, Paul Mackerras, sparclinux, Shubham Bansal,
linux-riscv, Will Deacon, Paul Burton, Paul Chaignon,
John Fastabend, Andrii Nakryiko, naveen.n.rao, Yonghong Song,
linux-mips, Xi Wang, Albert Ou, Johan Almbladh, Luke Nelson,
KP Singh, Paul Walmsley, linux-arm-kernel, Thomas Bogendoerfer,
Networking, open list, David S. Miller, Björn Töpel,
Palmer Dabbelt, bpf, linuxppc-dev, Martin KaFai Lau
In-Reply-To: <CAEf4BzZqoVZ7keWCLmC=A5oPPwj_xMNRWDkJUcjWn9yE_z1gSg@mail.gmail.com>
On 9/9/21 7:50 AM, Andrii Nakryiko wrote:
> On Wed, Sep 8, 2021 at 8:33 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>>
>> In the current code, the actual max tail call count is 33 which is greater
>> than MAX_TAIL_CALL_CNT (defined as 32), the actual limit is not consistent
>> with the meaning of MAX_TAIL_CALL_CNT, there is some confusion and need to
>> spend some time to think the reason at the first glance.
>
> think *about* the reason
>
>> We can see the historical evolution from commit 04fd61ab36ec ("bpf: allow
>> bpf programs to tail-call other bpf programs") and commit f9dabe016b63
>> ("bpf: Undo off-by-one in interpreter tail call count limit").
>>
>> In order to avoid changing existing behavior, the actual limit is 33 now,
>> this is resonable.
>
> typo: reasonable
>
>> After commit 874be05f525e ("bpf, tests: Add tail call test suite"), we can
>> see there exists failed testcase.
>>
>> On all archs when CONFIG_BPF_JIT_ALWAYS_ON is not set:
>> # echo 0 > /proc/sys/net/core/bpf_jit_enable
>> # modprobe test_bpf
>> # dmesg | grep -w FAIL
>> Tail call error path, max count reached jited:0 ret 34 != 33 FAIL
>>
>> On some archs:
>> # echo 1 > /proc/sys/net/core/bpf_jit_enable
>> # modprobe test_bpf
>> # dmesg | grep -w FAIL
>> Tail call error path, max count reached jited:1 ret 34 != 33 FAIL
>>
>> So it is necessary to change the value of MAX_TAIL_CALL_CNT from 32 to 33,
>> then do some small changes of the related code.
>>
>> With this patch, it does not change the current limit, MAX_TAIL_CALL_CNT
>> can reflect the actual max tail call count, and the above failed testcase
>> can be fixed.
>>
>> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
>> ---
>
> This change breaks selftests ([0]), please fix them at the same time
> as you are changing the kernel behavior:
The below selftests shouldn't have to change given there is no change in
behavior intended (MAX_TAIL_CALL_CNT is bumped to 33 but counter inc'ed
prior to the comparison). It just means that /all/ JITs must be changed
and in particular properly _tested_.
> test_tailcall_2:PASS:tailcall 128 nsec
> test_tailcall_2:PASS:tailcall 128 nsec
> test_tailcall_2:FAIL:tailcall err 0 errno 2 retval 4
> #135/2 tailcalls/tailcall_2:FAIL
> test_tailcall_3:PASS:tailcall 128 nsec
> test_tailcall_3:FAIL:tailcall count err 0 errno 2 count 34
> test_tailcall_3:PASS:tailcall 128 nsec
> #135/3 tailcalls/tailcall_3:FAIL
> #135/4 tailcalls/tailcall_4:OK
> #135/5 tailcalls/tailcall_5:OK
> #135/6 tailcalls/tailcall_bpf2bpf_1:OK
> test_tailcall_bpf2bpf_2:PASS:tailcall 128 nsec
> test_tailcall_bpf2bpf_2:FAIL:tailcall count err 0 errno 2 count 34
> test_tailcall_bpf2bpf_2:PASS:tailcall 128 nsec
> #135/7 tailcalls/tailcall_bpf2bpf_2:FAIL
> #135/8 tailcalls/tailcall_bpf2bpf_3:OK
> test_tailcall_bpf2bpf_4:PASS:tailcall 54 nsec
> test_tailcall_bpf2bpf_4:FAIL:tailcall count err 0 errno 2 count 32
> #135/9 tailcalls/tailcall_bpf2bpf_4:FAIL
> test_tailcall_bpf2bpf_4:PASS:tailcall 54 nsec
> test_tailcall_bpf2bpf_4:FAIL:tailcall count err 0 errno 2 count 32
> #135/10 tailcalls/tailcall_bpf2bpf_5:FAIL
> #135 tailcalls:FAIL
>
> [0] https://github.com/kernel-patches/bpf/pull/1747/checks?check_run_id=3552002906
>
>> arch/arm/net/bpf_jit_32.c | 11 ++++++-----
>> arch/arm64/net/bpf_jit_comp.c | 7 ++++---
>> arch/mips/net/ebpf_jit.c | 4 ++--
>> arch/powerpc/net/bpf_jit_comp32.c | 4 ++--
>> arch/powerpc/net/bpf_jit_comp64.c | 12 ++++++------
>> arch/riscv/net/bpf_jit_comp32.c | 4 ++--
>> arch/riscv/net/bpf_jit_comp64.c | 4 ++--
>> arch/sparc/net/bpf_jit_comp_64.c | 8 ++++----
>> include/linux/bpf.h | 2 +-
>> kernel/bpf/core.c | 4 ++--
>> 10 files changed, 31 insertions(+), 29 deletions(-)
>>
>
> [...]
>
^ permalink raw reply
* [PATCH v4] ftrace: Cleanup ftrace_dyn_arch_init()
From: Weizhao Ouyang @ 2021-09-09 9:02 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar
Cc: Rich Felker, linux-ia64, linux-sh, linux-mips,
James E.J. Bottomley, Guo Ren, H. Peter Anvin, sparclinux,
linux-riscv, Vincent Chen, Will Deacon, linux-s390,
Yoshinori Sato, Helge Deller, x86, Russell King, linux-csky,
Christian Borntraeger, Catalin Marinas, Albert Ou, Weizhao Ouyang,
Vasily Gorbik, Heiko Carstens, Borislav Petkov, Greentime Hu,
Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Michal Simek,
Thomas Bogendoerfer, linux-parisc, Nick Hu, linux-kernel,
Palmer Dabbelt, Paul Mackerras, linuxppc-dev, David S. Miller
Most of ARCHs use empty ftrace_dyn_arch_init(), introduce a weak common
ftrace_dyn_arch_init() to cleanup them.
Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com> (s390)
Acked-by: Helge Deller <deller@gmx.de> (parisc)
---
Changes in v4:
-- revert the generic declaration
Changes in v3:
-- fix unrecognized opcode on PowerPC
Changes in v2:
-- correct CONFIG_DYNAMIC_FTRACE on PowerPC
-- add Acked-by tag
---
arch/arm/kernel/ftrace.c | 5 -----
arch/arm64/kernel/ftrace.c | 5 -----
arch/csky/kernel/ftrace.c | 5 -----
arch/ia64/kernel/ftrace.c | 6 ------
arch/microblaze/kernel/ftrace.c | 5 -----
arch/nds32/kernel/ftrace.c | 5 -----
arch/parisc/kernel/ftrace.c | 5 -----
arch/riscv/kernel/ftrace.c | 5 -----
arch/s390/kernel/ftrace.c | 5 -----
arch/sh/kernel/ftrace.c | 5 -----
arch/sparc/kernel/ftrace.c | 5 -----
arch/x86/kernel/ftrace.c | 5 -----
kernel/trace/ftrace.c | 5 +++++
13 files changed, 5 insertions(+), 61 deletions(-)
diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
index 3c83b5d29697..a006585e1c09 100644
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -193,11 +193,6 @@ int ftrace_make_nop(struct module *mod,
return ret;
}
-
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
#endif /* CONFIG_DYNAMIC_FTRACE */
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 7f467bd9db7a..fc62dfe73f93 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -236,11 +236,6 @@ void arch_ftrace_update_code(int command)
command |= FTRACE_MAY_SLEEP;
ftrace_modify_all_code(command);
}
-
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
#endif /* CONFIG_DYNAMIC_FTRACE */
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
diff --git a/arch/csky/kernel/ftrace.c b/arch/csky/kernel/ftrace.c
index b4a7ec1517ff..50bfcf129078 100644
--- a/arch/csky/kernel/ftrace.c
+++ b/arch/csky/kernel/ftrace.c
@@ -133,11 +133,6 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
(unsigned long)func, true, true);
return ret;
}
-
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
#endif /* CONFIG_DYNAMIC_FTRACE */
#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
diff --git a/arch/ia64/kernel/ftrace.c b/arch/ia64/kernel/ftrace.c
index b2ab2d58fb30..d6360fd404ab 100644
--- a/arch/ia64/kernel/ftrace.c
+++ b/arch/ia64/kernel/ftrace.c
@@ -194,9 +194,3 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
flush_icache_range(addr, addr + 16);
return 0;
}
-
-/* run from kstop_machine */
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
diff --git a/arch/microblaze/kernel/ftrace.c b/arch/microblaze/kernel/ftrace.c
index 224eea40e1ee..188749d62709 100644
--- a/arch/microblaze/kernel/ftrace.c
+++ b/arch/microblaze/kernel/ftrace.c
@@ -163,11 +163,6 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
return ret;
}
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
-
int ftrace_update_ftrace_func(ftrace_func_t func)
{
unsigned long ip = (unsigned long)(&ftrace_call);
diff --git a/arch/nds32/kernel/ftrace.c b/arch/nds32/kernel/ftrace.c
index 0e23e3a8df6b..f0ef4842d191 100644
--- a/arch/nds32/kernel/ftrace.c
+++ b/arch/nds32/kernel/ftrace.c
@@ -84,11 +84,6 @@ void _ftrace_caller(unsigned long parent_ip)
/* restore all state needed by the compiler epilogue */
}
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
-
static unsigned long gen_sethi_insn(unsigned long addr)
{
unsigned long opcode = 0x46000000;
diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c
index 0a1e75af5382..01581f715737 100644
--- a/arch/parisc/kernel/ftrace.c
+++ b/arch/parisc/kernel/ftrace.c
@@ -94,11 +94,6 @@ int ftrace_disable_ftrace_graph_caller(void)
#endif
#ifdef CONFIG_DYNAMIC_FTRACE
-
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
int ftrace_update_ftrace_func(ftrace_func_t func)
{
return 0;
diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c
index 7f1e5203de88..4716f4cdc038 100644
--- a/arch/riscv/kernel/ftrace.c
+++ b/arch/riscv/kernel/ftrace.c
@@ -154,11 +154,6 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
return ret;
}
-
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
#endif
#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
diff --git a/arch/s390/kernel/ftrace.c b/arch/s390/kernel/ftrace.c
index 0a464d328467..3fd80397ff52 100644
--- a/arch/s390/kernel/ftrace.c
+++ b/arch/s390/kernel/ftrace.c
@@ -262,11 +262,6 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
return 0;
}
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
-
void arch_ftrace_update_code(int command)
{
if (ftrace_shared_hotpatch_trampoline(NULL))
diff --git a/arch/sh/kernel/ftrace.c b/arch/sh/kernel/ftrace.c
index 295c43315bbe..930001bb8c6a 100644
--- a/arch/sh/kernel/ftrace.c
+++ b/arch/sh/kernel/ftrace.c
@@ -252,11 +252,6 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
return ftrace_modify_code(rec->ip, old, new);
}
-
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
#endif /* CONFIG_DYNAMIC_FTRACE */
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
diff --git a/arch/sparc/kernel/ftrace.c b/arch/sparc/kernel/ftrace.c
index 684b84ce397f..eaead3da8e03 100644
--- a/arch/sparc/kernel/ftrace.c
+++ b/arch/sparc/kernel/ftrace.c
@@ -82,11 +82,6 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
new = ftrace_call_replace(ip, (unsigned long)func);
return ftrace_modify_code(ip, old, new);
}
-
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
#endif
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 1b3ce3b4a2a2..23d221a9a3cd 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -252,11 +252,6 @@ void arch_ftrace_update_code(int command)
ftrace_modify_all_code(command);
}
-int __init ftrace_dyn_arch_init(void)
-{
- return 0;
-}
-
/* Currently only x86_64 supports dynamic trampolines */
#ifdef CONFIG_X86_64
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 7efbc8aaf7f6..4c090323198d 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -6846,6 +6846,11 @@ void __init ftrace_free_init_mem(void)
ftrace_free_mem(NULL, start, end);
}
+int __init __weak ftrace_dyn_arch_init(void)
+{
+ return 0;
+}
+
void __init ftrace_init(void)
{
extern unsigned long __start_mcount_loc[];
--
2.30.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.14 080/252] hvsi: don't panic on tty_register_driver failure
From: Sasha Levin @ 2021-09-09 11:38 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linuxppc-dev, Jiri Slaby, Greg Kroah-Hartman
In-Reply-To: <20210909114106.141462-1-sashal@kernel.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index bfc15279d5bc..f0bc8e780051 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1038,7 +1038,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1069,12 +1069,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.13 069/219] hvsi: don't panic on tty_register_driver failure
From: Sasha Levin @ 2021-09-09 11:44 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linuxppc-dev, Jiri Slaby, Greg Kroah-Hartman
In-Reply-To: <20210909114635.143983-1-sashal@kernel.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index e8c58f9bd263..d6afaae1729a 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1038,7 +1038,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1069,12 +1069,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.10 055/176] hvsi: don't panic on tty_register_driver failure
From: Sasha Levin @ 2021-09-09 11:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linuxppc-dev, Jiri Slaby, Greg Kroah-Hartman
In-Reply-To: <20210909115118.146181-1-sashal@kernel.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index e8c58f9bd263..d6afaae1729a 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1038,7 +1038,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1069,12 +1069,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 037/109] hvsi: don't panic on tty_register_driver failure
From: Sasha Levin @ 2021-09-09 11:53 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linuxppc-dev, Jiri Slaby, Greg Kroah-Hartman
In-Reply-To: <20210909115507.147917-1-sashal@kernel.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index 66f95f758be0..73226337f561 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1038,7 +1038,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1069,12 +1069,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 27/74] hvsi: don't panic on tty_register_driver failure
From: Sasha Levin @ 2021-09-09 11:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linuxppc-dev, Jiri Slaby, Greg Kroah-Hartman
In-Reply-To: <20210909115726.149004-1-sashal@kernel.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index 66f95f758be0..73226337f561 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1038,7 +1038,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1069,12 +1069,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 25/59] hvsi: don't panic on tty_register_driver failure
From: Sasha Levin @ 2021-09-09 11:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linuxppc-dev, Jiri Slaby, Greg Kroah-Hartman
In-Reply-To: <20210909115900.149795-1-sashal@kernel.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index 2e578d6433af..7d7fdfc578a9 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1051,7 +1051,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1082,12 +1082,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 23/48] hvsi: don't panic on tty_register_driver failure
From: Sasha Levin @ 2021-09-09 11:59 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linuxppc-dev, Jiri Slaby, Greg Kroah-Hartman
In-Reply-To: <20210909120015.150411-1-sashal@kernel.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index 96ce6bd1cc6f..4b6f93067ae4 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1051,7 +1051,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1082,12 +1082,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 19/35] hvsi: don't panic on tty_register_driver failure
From: Sasha Levin @ 2021-09-09 12:01 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linuxppc-dev, Jiri Slaby, Greg Kroah-Hartman
In-Reply-To: <20210909120116.150912-1-sashal@kernel.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index a75146f600cb..3e29f5f0d4ca 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1051,7 +1051,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1082,12 +1082,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH v2 0/3] power: reset: Convert Power-Off driver to tristate
From: Lee Jones @ 2021-09-09 12:04 UTC (permalink / raw)
To: lee.jones
Cc: Rich Felker, linux-sh, Paul Walmsley, linux-mips,
James E . J . Bottomley, Max Filippov, Guo Ren, linux-csky,
sparclinux, linux-riscv, Will Deacon, Thomas Gleixner,
Anton Ivanov, Jonas Bonn, linux-s390, Brian Cain, linux-hexagon,
Helge Deller, Ley Foon Tan, Christian Borntraeger, Ingo Molnar,
linux-snps-arc, Jeff Dike, uclinux-h8-devel, linux-xtensa,
Albert Ou, Vasily Gorbik, Heiko Carstens, linux-um,
Stefan Kristiansson, Richard Weinberger, linux-m68k, openrisc,
Borislav Petkov, John Crispin, Stafford Horne, linux-arm-kernel,
Chris Zankel, Michal Simek, Yoshinori Sato, linux-parisc,
Vineet Gupta, linux-kernel, Palmer Dabbelt, linuxppc-dev,
David S . Miller
Provide support to compile the Power-Off driver as a module.
v1 => v2:
- s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/
Elliot Berman (2):
reboot: Export reboot_mode
power: reset: Enable tristate on restart power-off driver
Lee Jones (1):
arch: Export machine_restart() instances so they can be called from
modules
arch/arc/kernel/reset.c | 1 +
arch/arm/kernel/reboot.c | 1 +
arch/arm64/kernel/process.c | 1 +
arch/csky/kernel/power.c | 1 +
arch/h8300/kernel/process.c | 1 +
arch/hexagon/kernel/reset.c | 1 +
arch/m68k/kernel/process.c | 1 +
arch/microblaze/kernel/reset.c | 1 +
arch/mips/kernel/reset.c | 1 +
arch/mips/lantiq/falcon/reset.c | 1 +
arch/mips/sgi-ip27/ip27-reset.c | 1 +
arch/nds32/kernel/process.c | 2 +-
arch/nios2/kernel/process.c | 1 +
arch/openrisc/kernel/process.c | 1 +
arch/parisc/kernel/process.c | 1 +
arch/powerpc/kernel/setup-common.c | 1 +
arch/riscv/kernel/reset.c | 1 +
arch/s390/kernel/setup.c | 1 +
arch/sh/kernel/reboot.c | 1 +
arch/sparc/kernel/process_32.c | 1 +
arch/sparc/kernel/reboot.c | 1 +
arch/um/kernel/reboot.c | 1 +
arch/x86/kernel/reboot.c | 1 +
arch/xtensa/kernel/setup.c | 1 +
drivers/power/reset/Kconfig | 2 +-
kernel/reboot.c | 2 ++
26 files changed, 27 insertions(+), 2 deletions(-)
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Cain <bcain@codeaurora.org>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Chris Zankel <chris@zankel.net>
Cc: David S. Miller <davem@davemloft.net>
Cc: Guo Ren <guoren@kernel.org>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: John Crispin <john@phrozen.org>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Ley Foon Tan <ley.foon.tan@intel.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-csky@vger.kernel.org
Cc: linux-hexagon@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: linux-mips@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-riscv@lists.infradead.org
Cc: linux-s390@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-um@lists.infradead.org
Cc: linux-xtensa@linux-xtensa.org
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michal Simek <monstr@monstr.eu>
Cc: openrisc@lists.librecores.org
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Rich Felker <dalias@libc.org>
Cc: sparclinux@vger.kernel.org
Cc: Stafford Horne <shorne@gmail.com>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: uclinux-h8-devel@lists.sourceforge.jp
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Will Deacon <will@kernel.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
--
2.33.0.153.gba50c8fa24-goog
^ permalink raw reply
* [PATCH v2 1/3] arch: Export machine_restart() instances so they can be called from modules
From: Lee Jones @ 2021-09-09 12:04 UTC (permalink / raw)
To: lee.jones
Cc: Rich Felker, linux-sh, Catalin Marinas, John Crispin, linux-mips,
James E . J . Bottomley, Max Filippov, Guo Ren, linux-csky,
sparclinux, linux-hexagon, linux-riscv, Will Deacon,
Thomas Gleixner, Anton Ivanov, Jonas Bonn, linux-s390,
Yoshinori Sato, Helge Deller, Ley Foon Tan, Christian Borntraeger,
Ingo Molnar, Geert Uytterhoeven, linux-snps-arc, Jeff Dike,
uclinux-h8-devel, linux-xtensa, Albert Ou, Vasily Gorbik,
Heiko Carstens, linux-um, Stefan Kristiansson, linux-m68k,
openrisc, Borislav Petkov, Paul Walmsley, Stafford Horne,
linux-arm-kernel, Chris Zankel, Michal Simek, Thomas Bogendoerfer,
Brian Cain, linux-parisc, Vineet Gupta, linux-kernel,
Palmer Dabbelt, Richard Weinberger, linuxppc-dev,
David S . Miller
In-Reply-To: <20210909120421.1313908-1-lee.jones@linaro.org>
A recent attempt to convert the Power Reset Restart driver to tristate
failed because of the following compile error (reported once merged by
Stephen Rothwell via Linux Next):
ERROR: "machine_restart" [drivers/power/reset/restart-poweroff.ko] undefined!
This error occurs since some of the machine_restart() instances are
not currently exported for use in modules. This patch aims to rectify
that.
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Will Deacon <will@kernel.org>
Cc: Guo Ren <guoren@kernel.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Brian Cain <bcain@codeaurora.org>
Cc: Michal Simek <monstr@monstr.eu>
Cc: John Crispin <john@phrozen.org>
Cc: Ley Foon Tan <ley.foon.tan@intel.com>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Cc: Stafford Horne <shorne@gmail.com>
Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Rich Felker <dalias@libc.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-csky@vger.kernel.org
Cc: uclinux-h8-devel@lists.sourceforge.jp
Cc: linux-hexagon@vger.kernel.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: linux-mips@vger.kernel.org
Cc: openrisc@lists.librecores.org
Cc: linux-parisc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-riscv@lists.infradead.org
Cc: linux-s390@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: linux-um@lists.infradead.org
Cc: linux-xtensa@linux-xtensa.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
arch/arc/kernel/reset.c | 1 +
arch/arm/kernel/reboot.c | 1 +
arch/arm64/kernel/process.c | 1 +
arch/csky/kernel/power.c | 1 +
arch/h8300/kernel/process.c | 1 +
arch/hexagon/kernel/reset.c | 1 +
arch/m68k/kernel/process.c | 1 +
arch/microblaze/kernel/reset.c | 1 +
arch/mips/kernel/reset.c | 1 +
arch/mips/lantiq/falcon/reset.c | 1 +
arch/mips/sgi-ip27/ip27-reset.c | 1 +
arch/nds32/kernel/process.c | 2 +-
arch/nios2/kernel/process.c | 1 +
arch/openrisc/kernel/process.c | 1 +
arch/parisc/kernel/process.c | 1 +
arch/powerpc/kernel/setup-common.c | 1 +
arch/riscv/kernel/reset.c | 1 +
arch/s390/kernel/setup.c | 1 +
arch/sh/kernel/reboot.c | 1 +
arch/sparc/kernel/process_32.c | 1 +
arch/sparc/kernel/reboot.c | 1 +
arch/um/kernel/reboot.c | 1 +
arch/x86/kernel/reboot.c | 1 +
arch/xtensa/kernel/setup.c | 1 +
24 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arc/kernel/reset.c b/arch/arc/kernel/reset.c
index fd6c3eb930bad..1f5d8ce532e2f 100644
--- a/arch/arc/kernel/reset.c
+++ b/arch/arc/kernel/reset.c
@@ -20,6 +20,7 @@ void machine_restart(char *__unused)
pr_info("Put your restart handler here\n");
machine_halt();
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_power_off(void)
{
diff --git a/arch/arm/kernel/reboot.c b/arch/arm/kernel/reboot.c
index 3044fcb8d0736..95cdcb17251af 100644
--- a/arch/arm/kernel/reboot.c
+++ b/arch/arm/kernel/reboot.c
@@ -146,3 +146,4 @@ void machine_restart(char *cmd)
printk("Reboot failed -- System halted\n");
while (1);
}
+EXPORT_SYMBOL_GPL(machine_restart);
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index c8989b999250d..d7557f649dbd6 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -148,6 +148,7 @@ void machine_restart(char *cmd)
printk("Reboot failed -- System halted\n");
while (1);
}
+EXPORT_SYMBOL_GPL(machine_restart);
#define bstr(suffix, str) [PSR_BTYPE_ ## suffix >> PSR_BTYPE_SHIFT] = str
static const char *const btypes[] = {
diff --git a/arch/csky/kernel/power.c b/arch/csky/kernel/power.c
index 923ee4e381b81..1787de5b13ba6 100644
--- a/arch/csky/kernel/power.c
+++ b/arch/csky/kernel/power.c
@@ -28,3 +28,4 @@ void machine_restart(char *cmd)
do_kernel_restart(cmd);
asm volatile ("bkpt");
}
+EXPORT_SYMBOL_GPL(machine_restart);
diff --git a/arch/h8300/kernel/process.c b/arch/h8300/kernel/process.c
index 2ac27e4248a46..f92f473a1934a 100644
--- a/arch/h8300/kernel/process.c
+++ b/arch/h8300/kernel/process.c
@@ -66,6 +66,7 @@ void machine_restart(char *__unused)
local_irq_disable();
__asm__("jmp @@0");
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_halt(void)
{
diff --git a/arch/hexagon/kernel/reset.c b/arch/hexagon/kernel/reset.c
index da36114d928f0..ed79e0e5a0318 100644
--- a/arch/hexagon/kernel/reset.c
+++ b/arch/hexagon/kernel/reset.c
@@ -19,6 +19,7 @@ void machine_halt(void)
void machine_restart(char *cmd)
{
}
+EXPORT_SYMBOL_GPL(machine_restart);
void (*pm_power_off)(void) = NULL;
EXPORT_SYMBOL(pm_power_off);
diff --git a/arch/m68k/kernel/process.c b/arch/m68k/kernel/process.c
index db49f90917112..f891d9b4bdf2f 100644
--- a/arch/m68k/kernel/process.c
+++ b/arch/m68k/kernel/process.c
@@ -57,6 +57,7 @@ void machine_restart(char * __unused)
mach_reset();
for (;;);
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_halt(void)
{
diff --git a/arch/microblaze/kernel/reset.c b/arch/microblaze/kernel/reset.c
index 5f4722908164d..7f47e59914c0d 100644
--- a/arch/microblaze/kernel/reset.c
+++ b/arch/microblaze/kernel/reset.c
@@ -41,3 +41,4 @@ void machine_restart(char *cmd)
pr_emerg("Reboot failed -- System halted\n");
while (1);
}
+EXPORT_SYMBOL_GPL(machine_restart);
diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 6288780b779e7..4fe2edc2d06d6 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -99,6 +99,7 @@ void machine_restart(char *command)
pr_emerg("Reboot failed -- System halted\n");
machine_hang();
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_halt(void)
{
diff --git a/arch/mips/lantiq/falcon/reset.c b/arch/mips/lantiq/falcon/reset.c
index 261996c230cf6..70259dd09aaea 100644
--- a/arch/mips/lantiq/falcon/reset.c
+++ b/arch/mips/lantiq/falcon/reset.c
@@ -51,6 +51,7 @@ static void machine_restart(char *command)
(void *)WDT_REG_BASE);
unreachable();
}
+EXPORT_SYMBOL_GPL(machine_restart);
static void machine_halt(void)
{
diff --git a/arch/mips/sgi-ip27/ip27-reset.c b/arch/mips/sgi-ip27/ip27-reset.c
index 5ac5ad6387343..35084653022ea 100644
--- a/arch/mips/sgi-ip27/ip27-reset.c
+++ b/arch/mips/sgi-ip27/ip27-reset.c
@@ -29,6 +29,7 @@
#include "ip27-common.h"
void machine_restart(char *command) __noreturn;
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_halt(void) __noreturn;
void machine_power_off(void) __noreturn;
diff --git a/arch/nds32/kernel/process.c b/arch/nds32/kernel/process.c
index 391895b54d13c..f60b70fcfaf3d 100644
--- a/arch/nds32/kernel/process.c
+++ b/arch/nds32/kernel/process.c
@@ -91,7 +91,7 @@ void machine_restart(char *cmd)
while (1) ;
}
-EXPORT_SYMBOL(machine_restart);
+EXPORT_SYMBOL_GPL(machine_restart);
void show_regs(struct pt_regs *regs)
{
diff --git a/arch/nios2/kernel/process.c b/arch/nios2/kernel/process.c
index 9ff37ba2bb603..ebc4940059de5 100644
--- a/arch/nios2/kernel/process.c
+++ b/arch/nios2/kernel/process.c
@@ -51,6 +51,7 @@ void machine_restart(char *__unused)
: "r" (cpuinfo.reset_addr)
: "r4");
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_halt(void)
{
diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
index eb62429681fc8..fba2aa6ae8470 100644
--- a/arch/openrisc/kernel/process.c
+++ b/arch/openrisc/kernel/process.c
@@ -61,6 +61,7 @@ void machine_restart(char *cmd)
pr_emerg("Reboot failed -- System halted\n");
while (1);
}
+EXPORT_SYMBOL_GPL(machine_restart);
/*
* Similar to machine_power_off, but don't shut off power. Add code
diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
index 184ec3c1eae44..f39f7620d715d 100644
--- a/arch/parisc/kernel/process.c
+++ b/arch/parisc/kernel/process.c
@@ -96,6 +96,7 @@ void machine_restart(char *cmd)
while (1) ;
}
+EXPORT_SYMBOL_GPL(machine_restart);
void (*chassis_power_off)(void);
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index aa9c2d01424af..dfd875d4f8478 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -158,6 +158,7 @@ void machine_restart(char *cmd)
machine_hang();
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_power_off(void)
{
diff --git a/arch/riscv/kernel/reset.c b/arch/riscv/kernel/reset.c
index ee5878d968cc1..5fd0aa3e12766 100644
--- a/arch/riscv/kernel/reset.c
+++ b/arch/riscv/kernel/reset.c
@@ -20,6 +20,7 @@ void machine_restart(char *cmd)
do_kernel_restart(cmd);
while (1);
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_halt(void)
{
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index ff0f9e8389162..ce8afa1cf8645 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -278,6 +278,7 @@ void machine_restart(char *command)
console_unblank();
_machine_restart(command);
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_halt(void)
{
diff --git a/arch/sh/kernel/reboot.c b/arch/sh/kernel/reboot.c
index 5c33f036418be..ea4b1bdada41a 100644
--- a/arch/sh/kernel/reboot.c
+++ b/arch/sh/kernel/reboot.c
@@ -83,6 +83,7 @@ void machine_restart(char *cmd)
{
machine_ops.restart(cmd);
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_halt(void)
{
diff --git a/arch/sparc/kernel/process_32.c b/arch/sparc/kernel/process_32.c
index 93983d6d431de..de9106e386919 100644
--- a/arch/sparc/kernel/process_32.c
+++ b/arch/sparc/kernel/process_32.c
@@ -104,6 +104,7 @@ void machine_restart(char * cmd)
prom_feval ("reset");
panic("Reboot failed!");
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_power_off(void)
{
diff --git a/arch/sparc/kernel/reboot.c b/arch/sparc/kernel/reboot.c
index 69c1b6c047d53..faebf958c4b5a 100644
--- a/arch/sparc/kernel/reboot.c
+++ b/arch/sparc/kernel/reboot.c
@@ -52,4 +52,5 @@ void machine_restart(char *cmd)
prom_reboot("");
panic("Reboot failed!");
}
+EXPORT_SYMBOL_GPL(machine_restart);
diff --git a/arch/um/kernel/reboot.c b/arch/um/kernel/reboot.c
index 48c0610d506e0..7ca141cf4a0af 100644
--- a/arch/um/kernel/reboot.c
+++ b/arch/um/kernel/reboot.c
@@ -47,6 +47,7 @@ void machine_restart(char * __unused)
uml_cleanup();
reboot_skas();
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_power_off(void)
{
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index ebfb911082326..d378e80a60a1b 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -733,6 +733,7 @@ static void native_machine_restart(char *__unused)
machine_shutdown();
__machine_emergency_restart(0);
}
+EXPORT_SYMBOL_GPL(machine_restart);
static void native_machine_halt(void)
{
diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
index ed184106e4cf9..a70c1351cd59e 100644
--- a/arch/xtensa/kernel/setup.c
+++ b/arch/xtensa/kernel/setup.c
@@ -564,6 +564,7 @@ void machine_restart(char * cmd)
{
platform_restart();
}
+EXPORT_SYMBOL_GPL(machine_restart);
void machine_halt(void)
{
--
2.33.0.153.gba50c8fa24-goog
^ permalink raw reply related
* Re: [PATCH 1/3] perf: Add macros to specify onchip L2/L3 accesses
From: Michael Ellerman @ 2021-09-09 12:45 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mark.rutland, atrajeev, ak, daniel, rnsastry, alexander.shishkin,
Kajol Jain, linux-kernel, acme, ast, linux-perf-users, yao.jin,
mingo, paulus, maddy, jolsa, namhyung, songliubraving,
linuxppc-dev, kan.liang
In-Reply-To: <YTiBqbxe7ieqY2OE@hirez.programming.kicks-ass.net>
Peter Zijlstra <peterz@infradead.org> writes:
> On Wed, Sep 08, 2021 at 05:17:53PM +1000, Michael Ellerman wrote:
>> Kajol Jain <kjain@linux.ibm.com> writes:
>
>> > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
>> > index f92880a15645..030b3e990ac3 100644
>> > --- a/include/uapi/linux/perf_event.h
>> > +++ b/include/uapi/linux/perf_event.h
>> > @@ -1265,7 +1265,9 @@ union perf_mem_data_src {
>> > #define PERF_MEM_LVLNUM_L2 0x02 /* L2 */
>> > #define PERF_MEM_LVLNUM_L3 0x03 /* L3 */
>> > #define PERF_MEM_LVLNUM_L4 0x04 /* L4 */
>> > -/* 5-0xa available */
>> > +#define PERF_MEM_LVLNUM_OC_L2 0x05 /* On Chip L2 */
>> > +#define PERF_MEM_LVLNUM_OC_L3 0x06 /* On Chip L3 */
>>
>> The obvious use for 5 is for "L5" and so on.
>>
>> I'm not sure adding new levels is the best idea, because these don't fit
>> neatly into the hierarchy, they are off to the side.
>>
>>
>> I wonder if we should use the remote field.
>>
>> ie. for another core's L2 we set:
>>
>> mem_lvl = PERF_MEM_LVL_L2
>> mem_remote = 1
>
> This mixes APIs (see below), IIUC the correct usage would be something
> like: lvl_num=L2 remote=1
Aha, I was wondering how lvl and lvl_num were supposed to interact.
>> Which would mean "remote L2", but not remote enough to be
>> lvl = PERF_MEM_LVL_REM_CCE1.
>>
>> It would be printed by the existing tools/perf code as "Remote L2", vs
>> "Remote cache (1 hop)", which seems OK.
>>
>>
>> ie. we'd be able to express:
>>
>> Current core's L2: LVL_L2
>> Other core's L2: LVL_L2 | REMOTE
>> Other chip's L2: LVL_REM_CCE1 | REMOTE
>>
>> And similarly for L3.
>>
>> I think that makes sense? Unless people think remote should be reserved
>> to mean on another chip, though we already have REM_CCE1 for that.
>
> IIRC the PERF_MEM_LVL_* namespace is somewhat depricated in favour of
> the newer composite PERF_MEM_{LVLNUM_,REMOTE_,SNOOPX_} fields. Of
> course, ABIs being what they are, we get to support both :/ But I'm not
> sure mixing them is a great idea.
OK.
> Also, clearly this could use a comment...
>
> The 'new' composite doesnt have a hops field because the hardware that
> nessecitated that change doesn't report it, but we could easily add a
> field there.
>
> Suppose we add, mem_hops:3 (would 6 hops be too small?) and the
> corresponding PERF_MEM_HOPS_{NA, 0..6}
It's really 7 if we use remote && hop = 0 to mean the first hop.
If we're wanting to use some of the hop levels to represent
intra-chip/package hops then we could possibly use them all on a really
big system.
eg. you could imagine something like:
L2 | - local L2
L2 | REMOTE | HOPS_0 - L2 of neighbour core
L2 | REMOTE | HOPS_1 - L2 of near core on same chip (same 1/2 of chip)
L2 | REMOTE | HOPS_2 - L2 of far core on same chip (other 1/2 of chip)
L2 | REMOTE | HOPS_3 - L2 of sibling chip in same package
L2 | REMOTE | HOPS_4 - L2 on separate package 1 hop away
L2 | REMOTE | HOPS_5 - L2 on separate package 2 hops away
L2 | REMOTE | HOPS_6 - L2 on separate package 3 hops away
Whether it's useful to represent all those levels I'm not sure, but it's
probably good if we have the ability.
I guess I'm 50/50 on whether that's enough levels, or whether we want
another bit to allow for future growth.
> Then I suppose you can encode things like:
>
> L2 - local L2
> L2 | REMOTE - remote L2 at an unspecified distance (NA)
> L2 | REMOTE | HOPS_0 - remote L2 on the same node
> L2 | REMOTE | HOPS_1 - remote L2 on a node 1 removed
>
> Would that work?
Yeah that looks good to me.
cheers
^ permalink raw reply
* Re: [PATCH v3 0/8] Implement generic cc_platform_has() helper function
From: Tom Lendacky @ 2021-09-09 13:01 UTC (permalink / raw)
To: Christian Borntraeger, 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, Brijesh Singh, David Airlie,
Dave Hansen, Paul Mackerras, Will Deacon, Ard Biesheuvel,
Andi Kleen, Baoquan He, Joerg Roedel, Christoph Hellwig,
Peter Zijlstra, Ingo Molnar, Dave Young, Tianyu Lan,
Thomas Zimmermann, Vasily Gorbik, Heiko Carstens,
Maarten Lankhorst, Maxime Ripard, Borislav Petkov,
Andy Lutomirski, Thomas Gleixner, Daniel Vetter
In-Reply-To: <bde05ba8-c1b7-5df7-4147-44c38f4f3acf@de.ibm.com>
On 9/9/21 2:32 AM, Christian Borntraeger wrote:
>
>
> On 09.09.21 00:58, Tom Lendacky wrote:
>> This patch series provides a generic helper function, cc_platform_has(),
>> to replace the sme_active(), sev_active(), sev_es_active() and
>> mem_encrypt_active() functions.
>>
>> It is expected that as new confidential computing technologies are
>> added to the kernel, they can all be covered by a single function call
>> instead of a collection of specific function calls all called from the
>> same locations.
>>
>> The powerpc and s390 patches have been compile tested only. Can the
>> folks copied on this series verify that nothing breaks for them.
>
> Is there a tree somewhere?
I pushed it up to github:
https://github.com/AMDESE/linux/tree/prot-guest-has-v3
Thanks,
Tom
>
> Also,
>> a new file, arch/powerpc/platforms/pseries/cc_platform.c, has been
>> created for powerpc to hold the out of line function.
>>
>> Cc: Andi Kleen <ak@linux.intel.com>
>> Cc: Andy Lutomirski <luto@kernel.org>
>> Cc: Ard Biesheuvel <ardb@kernel.org>
>> Cc: Baoquan He <bhe@redhat.com>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
>> Cc: Daniel Vetter <daniel@ffwll.ch>
>> Cc: Dave Hansen <dave.hansen@linux.intel.com>
>> Cc: Dave Young <dyoung@redhat.com>
>> Cc: David Airlie <airlied@linux.ie>
>> Cc: Heiko Carstens <hca@linux.ibm.com>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Joerg Roedel <joro@8bytes.org>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Cc: Maxime Ripard <mripard@kernel.org>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: Vasily Gorbik <gor@linux.ibm.com>
>> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Christoph Hellwig <hch@infradead.org>
>>
>> ---
>>
>> Patches based on:
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git&data=04%7C01%7Cthomas.lendacky%40amd.com%7C5cd71ef2c2ce4b90060708d973640358%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637667695657121432%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FVngrPSxCCRKutAaIMtU2Nk8WArFQB1dEE2wN7v8RgA%3D&reserved=0
>> master
>> 4b93c544e90e ("thunderbolt: test: split up test cases in
>> tb_test_credit_alloc_all")
>>
>> Changes since v2:
>> - Changed the name from prot_guest_has() to cc_platform_has()
>> - Took the cc_platform_has() function out of line. Created two new files,
>> cc_platform.c, in both x86 and ppc to implment the function. As a
>> result, also changed the attribute defines into enums.
>> - Removed any received Reviewed-by's and Acked-by's given changes in this
>> version.
>> - Added removal of new instances of mem_encrypt_active() usage in powerpc
>> arch.
>> - Based on latest Linux tree to pick up powerpc changes related to the
>> mem_encrypt_active() function.
>>
>> Changes since v1:
>> - Moved some arch ioremap functions within #ifdef CONFIG_AMD_MEM_ENCRYPT
>> in prep for use of prot_guest_has() by TDX.
>> - Added type includes to the the protected_guest.h header file to prevent
>> build errors outside of x86.
>> - Made amd_prot_guest_has() EXPORT_SYMBOL_GPL
>> - Used amd_prot_guest_has() in place of checking sme_me_mask in the
>> arch/x86/mm/mem_encrypt.c file.
>>
>> Tom Lendacky (8):
>> x86/ioremap: Selectively build arch override encryption functions
>> mm: Introduce a function to check for confidential computing features
>> x86/sev: Add an x86 version of cc_platform_has()
>> powerpc/pseries/svm: Add a powerpc version of cc_platform_has()
>> x86/sme: Replace occurrences of sme_active() with cc_platform_has()
>> x86/sev: Replace occurrences of sev_active() with cc_platform_has()
>> x86/sev: Replace occurrences of sev_es_active() with cc_platform_has()
>> treewide: Replace the use of mem_encrypt_active() with
>> cc_platform_has()
>>
>> arch/Kconfig | 3 +
>> arch/powerpc/include/asm/mem_encrypt.h | 5 --
>> arch/powerpc/platforms/pseries/Kconfig | 1 +
>> arch/powerpc/platforms/pseries/Makefile | 2 +
>> arch/powerpc/platforms/pseries/cc_platform.c | 26 ++++++
>> arch/powerpc/platforms/pseries/svm.c | 5 +-
>> arch/s390/include/asm/mem_encrypt.h | 2 -
>> arch/x86/Kconfig | 1 +
>> arch/x86/include/asm/io.h | 8 ++
>> arch/x86/include/asm/kexec.h | 2 +-
>> arch/x86/include/asm/mem_encrypt.h | 14 +---
>> arch/x86/kernel/Makefile | 3 +
>> arch/x86/kernel/cc_platform.c | 21 +++++
>> arch/x86/kernel/crash_dump_64.c | 4 +-
>> arch/x86/kernel/head64.c | 4 +-
>> arch/x86/kernel/kvm.c | 3 +-
>> arch/x86/kernel/kvmclock.c | 4 +-
>> arch/x86/kernel/machine_kexec_64.c | 19 +++--
>> arch/x86/kernel/pci-swiotlb.c | 9 +-
>> arch/x86/kernel/relocate_kernel_64.S | 2 +-
>> arch/x86/kernel/sev.c | 6 +-
>> arch/x86/kvm/svm/svm.c | 3 +-
>> arch/x86/mm/ioremap.c | 18 ++--
>> arch/x86/mm/mem_encrypt.c | 57 +++++++------
>> arch/x86/mm/mem_encrypt_identity.c | 3 +-
>> arch/x86/mm/pat/set_memory.c | 3 +-
>> arch/x86/platform/efi/efi_64.c | 9 +-
>> arch/x86/realmode/init.c | 8 +-
>> 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/init.c | 7 +-
>> drivers/iommu/amd/iommu.c | 3 +-
>> drivers/iommu/amd/iommu_v2.c | 3 +-
>> drivers/iommu/iommu.c | 3 +-
>> fs/proc/vmcore.c | 6 +-
>> include/linux/cc_platform.h | 88 ++++++++++++++++++++
>> include/linux/mem_encrypt.h | 4 -
>> kernel/dma/swiotlb.c | 4 +-
>> 40 files changed, 267 insertions(+), 114 deletions(-)
>> create mode 100644 arch/powerpc/platforms/pseries/cc_platform.c
>> create mode 100644 arch/x86/kernel/cc_platform.c
>> create mode 100644 include/linux/cc_platform.h
>>
>>
>> base-commit: 4b93c544e90e2b28326182d31ee008eb80e02074
>>
^ permalink raw reply
* Re: [PATCH v3 8/8] treewide: Replace the use of mem_encrypt_active() with cc_platform_has()
From: Tom Lendacky @ 2021-09-09 13:10 UTC (permalink / raw)
To: Christophe Leroy, 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, Brijesh Singh, David Airlie,
Dave Hansen, Paul Mackerras, Will Deacon, Andi Kleen, Baoquan He,
Christian Borntraeger, Joerg Roedel, Christoph Hellwig,
Peter Zijlstra, Ingo Molnar, Dave Young, Tianyu Lan,
Daniel Vetter, Vasily Gorbik, Heiko Carstens, Maarten Lankhorst,
Maxime Ripard, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
Thomas Zimmermann
In-Reply-To: <a9d9a6a7-b3b3-570c-ef3d-2f5f0b61eb0b@csgroup.eu>
On 9/9/21 2:25 AM, Christophe Leroy wrote:
>
>
> On 9/8/21 10:58 PM, Tom Lendacky wrote:
>>
>> diff --git a/arch/powerpc/include/asm/mem_encrypt.h
>> b/arch/powerpc/include/asm/mem_encrypt.h
>> index ba9dab07c1be..2f26b8fc8d29 100644
>> --- a/arch/powerpc/include/asm/mem_encrypt.h
>> +++ b/arch/powerpc/include/asm/mem_encrypt.h
>> @@ -10,11 +10,6 @@
>> #include <asm/svm.h>
>> -static inline bool mem_encrypt_active(void)
>> -{
>> - return is_secure_guest();
>> -}
>> -
>> static inline bool force_dma_unencrypted(struct device *dev)
>> {
>> return is_secure_guest();
>> diff --git a/arch/powerpc/platforms/pseries/svm.c
>> b/arch/powerpc/platforms/pseries/svm.c
>> index 87f001b4c4e4..c083ecbbae4d 100644
>> --- a/arch/powerpc/platforms/pseries/svm.c
>> +++ b/arch/powerpc/platforms/pseries/svm.c
>> @@ -8,6 +8,7 @@
>> #include <linux/mm.h>
>> #include <linux/memblock.h>
>> +#include <linux/cc_platform.h>
>> #include <asm/machdep.h>
>> #include <asm/svm.h>
>> #include <asm/swiotlb.h>
>> @@ -63,7 +64,7 @@ void __init svm_swiotlb_init(void)
>> int set_memory_encrypted(unsigned long addr, int numpages)
>> {
>> - if (!mem_encrypt_active())
>> + if (!cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>> return 0;
>> if (!PAGE_ALIGNED(addr))
>> @@ -76,7 +77,7 @@ int set_memory_encrypted(unsigned long addr, int
>> numpages)
>> int set_memory_decrypted(unsigned long addr, int numpages)
>> {
>> - if (!mem_encrypt_active())
>> + if (!cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>> return 0;
>> if (!PAGE_ALIGNED(addr))
>
> This change unnecessarily complexifies the two functions. This is due to
> cc_platform_has() being out-line. It should really remain inline.
Please see previous discussion(s) on this series for why the function is
implemented out of line and for the naming:
V1: https://lore.kernel.org/lkml/cover.1627424773.git.thomas.lendacky@amd.com/
V2: https://lore.kernel.org/lkml/cover.1628873970.git.thomas.lendacky@amd.com/
Thanks,
Tom
>
> Before the change we got:
>
> 0000000000000000 <.set_memory_encrypted>:
> 0: 7d 20 00 a6 mfmsr r9
> 4: 75 29 00 40 andis. r9,r9,64
> 8: 41 82 00 48 beq 50 <.set_memory_encrypted+0x50>
> c: 78 69 04 20 clrldi r9,r3,48
> 10: 2c 29 00 00 cmpdi r9,0
> 14: 40 82 00 4c bne 60 <.set_memory_encrypted+0x60>
> 18: 7c 08 02 a6 mflr r0
> 1c: 7c 85 23 78 mr r5,r4
> 20: 78 64 85 02 rldicl r4,r3,48,20
> 24: 61 23 f1 34 ori r3,r9,61748
> 28: f8 01 00 10 std r0,16(r1)
> 2c: f8 21 ff 91 stdu r1,-112(r1)
> 30: 48 00 00 01 bl 30 <.set_memory_encrypted+0x30>
> 30: R_PPC64_REL24 .ucall_norets
> 34: 60 00 00 00 nop
> 38: 38 60 00 00 li r3,0
> 3c: 38 21 00 70 addi r1,r1,112
> 40: e8 01 00 10 ld r0,16(r1)
> 44: 7c 08 03 a6 mtlr r0
> 48: 4e 80 00 20 blr
> 50: 38 60 00 00 li r3,0
> 54: 4e 80 00 20 blr
> 60: 38 60 ff ea li r3,-22
> 64: 4e 80 00 20 blr
>
> After the change we get:
>
> 0000000000000000 <.set_memory_encrypted>:
> 0: 7c 08 02 a6 mflr r0
> 4: fb c1 ff f0 std r30,-16(r1)
> 8: fb e1 ff f8 std r31,-8(r1)
> c: 7c 7f 1b 78 mr r31,r3
> 10: 38 60 00 00 li r3,0
> 14: 7c 9e 23 78 mr r30,r4
> 18: f8 01 00 10 std r0,16(r1)
> 1c: f8 21 ff 81 stdu r1,-128(r1)
> 20: 48 00 00 01 bl 20 <.set_memory_encrypted+0x20>
> 20: R_PPC64_REL24 .cc_platform_has
> 24: 60 00 00 00 nop
> 28: 2c 23 00 00 cmpdi r3,0
> 2c: 41 82 00 44 beq 70 <.set_memory_encrypted+0x70>
> 30: 7b e9 04 20 clrldi r9,r31,48
> 34: 2c 29 00 00 cmpdi r9,0
> 38: 40 82 00 58 bne 90 <.set_memory_encrypted+0x90>
> 3c: 38 60 00 00 li r3,0
> 40: 7f c5 f3 78 mr r5,r30
> 44: 7b e4 85 02 rldicl r4,r31,48,20
> 48: 60 63 f1 34 ori r3,r3,61748
> 4c: 48 00 00 01 bl 4c <.set_memory_encrypted+0x4c>
> 4c: R_PPC64_REL24 .ucall_norets
> 50: 60 00 00 00 nop
> 54: 38 60 00 00 li r3,0
> 58: 38 21 00 80 addi r1,r1,128
> 5c: e8 01 00 10 ld r0,16(r1)
> 60: eb c1 ff f0 ld r30,-16(r1)
> 64: eb e1 ff f8 ld r31,-8(r1)
> 68: 7c 08 03 a6 mtlr r0
> 6c: 4e 80 00 20 blr
> 70: 38 21 00 80 addi r1,r1,128
> 74: 38 60 00 00 li r3,0
> 78: e8 01 00 10 ld r0,16(r1)
> 7c: eb c1 ff f0 ld r30,-16(r1)
> 80: eb e1 ff f8 ld r31,-8(r1)
> 84: 7c 08 03 a6 mtlr r0
> 88: 4e 80 00 20 blr
> 90: 38 60 ff ea li r3,-22
> 94: 4b ff ff c4 b 58 <.set_memory_encrypted+0x58>
>
^ permalink raw reply
* Re: [PATCH 1/3] perf: Add macros to specify onchip L2/L3 accesses
From: Peter Zijlstra @ 2021-09-09 14:36 UTC (permalink / raw)
To: Michael Ellerman
Cc: mark.rutland, atrajeev, ak, daniel, rnsastry, alexander.shishkin,
Kajol Jain, linux-kernel, acme, ast, linux-perf-users, yao.jin,
mingo, paulus, maddy, jolsa, namhyung, songliubraving,
linuxppc-dev, kan.liang
In-Reply-To: <87czphnchp.fsf@mpe.ellerman.id.au>
On Thu, Sep 09, 2021 at 10:45:54PM +1000, Michael Ellerman wrote:
> > The 'new' composite doesnt have a hops field because the hardware that
> > nessecitated that change doesn't report it, but we could easily add a
> > field there.
> >
> > Suppose we add, mem_hops:3 (would 6 hops be too small?) and the
> > corresponding PERF_MEM_HOPS_{NA, 0..6}
>
> It's really 7 if we use remote && hop = 0 to mean the first hop.
I don't think we can do that, becaus of backward compat. Currently:
lvl_num=DRAM, remote=1
denites: "Remote DRAM of any distance". Effectively it would have the new
hops field filled with zeros though, so if you then decode with the hops
field added it suddenly becomes:
lvl_num=DRAM, remote=1, hops=0
and reads like: "Remote DRAM of 0 hops" which is quite daft. Therefore 0
really must denote a 'N/A'.
> If we're wanting to use some of the hop levels to represent
> intra-chip/package hops then we could possibly use them all on a really
> big system.
>
> eg. you could imagine something like:
>
> L2 | - local L2
> L2 | REMOTE | HOPS_0 - L2 of neighbour core
> L2 | REMOTE | HOPS_1 - L2 of near core on same chip (same 1/2 of chip)
> L2 | REMOTE | HOPS_2 - L2 of far core on same chip (other 1/2 of chip)
> L2 | REMOTE | HOPS_3 - L2 of sibling chip in same package
> L2 | REMOTE | HOPS_4 - L2 on separate package 1 hop away
> L2 | REMOTE | HOPS_5 - L2 on separate package 2 hops away
> L2 | REMOTE | HOPS_6 - L2 on separate package 3 hops away
>
>
> Whether it's useful to represent all those levels I'm not sure, but it's
> probably good if we have the ability.
I'm thinking we ought to keep hops as steps along the NUMA fabric, with
0 hops being the local node. That only gets us:
L2, remote=0, hops=HOPS_0 -- our L2
L2, remote=1, hops=HOPS_0 -- L2 on the local node but not ours
L2, remote=1, hops!=HOPS_0 -- L2 on a remote node
> I guess I'm 50/50 on whether that's enough levels, or whether we want
> another bit to allow for future growth.
Right, possibly safer to add one extra bit while we can.... I suppose.
^ permalink raw reply
* Re: [PATCH v4] ftrace: Cleanup ftrace_dyn_arch_init()
From: Steven Rostedt @ 2021-09-09 23:36 UTC (permalink / raw)
To: Weizhao Ouyang
Cc: Rich Felker, linux-ia64, linux-sh, linux-mips,
James E.J. Bottomley, Guo Ren, H. Peter Anvin, sparclinux,
linux-riscv, Vincent Chen, Will Deacon, linux-s390,
Yoshinori Sato, Helge Deller, x86, Russell King, linux-csky,
Christian Borntraeger, Ingo Molnar, Catalin Marinas, Albert Ou,
Vasily Gorbik, Heiko Carstens, Borislav Petkov, Greentime Hu,
Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Michal Simek,
Thomas Bogendoerfer, linux-parisc, Nick Hu, linux-kernel,
Palmer Dabbelt, Paul Mackerras, linuxppc-dev, David S. Miller
In-Reply-To: <20210909090216.1955240-1-o451686892@gmail.com>
On Thu, 9 Sep 2021 17:02:16 +0800
Weizhao Ouyang <o451686892@gmail.com> wrote:
> Most of ARCHs use empty ftrace_dyn_arch_init(), introduce a weak common
> ftrace_dyn_arch_init() to cleanup them.
FYI,
I'm not ignoring this patch. I just wont be able to look at it until the
merge window is over.
-- Steve
>
> Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
> Acked-by: Heiko Carstens <hca@linux.ibm.com> (s390)
> Acked-by: Helge Deller <deller@gmx.de> (parisc)
>
> ---
> Changes in v4:
> -- revert the generic declaration
>
> Changes in v3:
> -- fix unrecognized opcode on PowerPC
>
> Changes in v2:
> -- correct CONFIG_DYNAMIC_FTRACE on PowerPC
> -- add Acked-by tag
>
> ---
> arch/arm/kernel/ftrace.c | 5 -----
> arch/arm64/kernel/ftrace.c | 5 -----
> arch/csky/kernel/ftrace.c | 5 -----
> arch/ia64/kernel/ftrace.c | 6 ------
> arch/microblaze/kernel/ftrace.c | 5 -----
> arch/nds32/kernel/ftrace.c | 5 -----
> arch/parisc/kernel/ftrace.c | 5 -----
> arch/riscv/kernel/ftrace.c | 5 -----
> arch/s390/kernel/ftrace.c | 5 -----
> arch/sh/kernel/ftrace.c | 5 -----
> arch/sparc/kernel/ftrace.c | 5 -----
> arch/x86/kernel/ftrace.c | 5 -----
> kernel/trace/ftrace.c | 5 +++++
> 13 files changed, 5 insertions(+), 61 deletions(-)
>
>
^ permalink raw reply
* [PATCH AUTOSEL 5.14 32/99] powerpc: make the install target not depend on any build artifact
From: Sasha Levin @ 2021-09-10 0:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Masahiro Yamada, Nick Desaulniers, linuxppc-dev
In-Reply-To: <20210910001558.173296-1-sashal@kernel.org>
From: Masahiro Yamada <masahiroy@kernel.org>
[ Upstream commit 9bef456b20581e630ef9a13555ca04fed65a859d ]
The install target should not depend on any build artifact.
The reason is explained in commit 19514fc665ff ("arm, kbuild: make
"make install" not depend on vmlinux").
Change the PowerPC installation code in a similar way.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210729141937.445051-2-masahiroy@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/boot/Makefile | 2 +-
arch/powerpc/boot/install.sh | 14 ++++++++++++++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e312ea802aa6..b90e53e413c8 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -445,7 +445,7 @@ $(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
$(Q)rm -f $@; ln $< $@
# Only install the vmlinux
-install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
+install:
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)"
# Install the vmlinux and other built boot targets.
diff --git a/arch/powerpc/boot/install.sh b/arch/powerpc/boot/install.sh
index b6a256bc96ee..8d669cf1ccda 100644
--- a/arch/powerpc/boot/install.sh
+++ b/arch/powerpc/boot/install.sh
@@ -21,6 +21,20 @@
# Bail with error code if anything goes wrong
set -e
+verify () {
+ if [ ! -f "$1" ]; then
+ echo "" 1>&2
+ echo " *** Missing file: $1" 1>&2
+ echo ' *** You need to run "make" before "make install".' 1>&2
+ echo "" 1>&2
+ exit 1
+ fi
+}
+
+# Make sure the files actually exist
+verify "$2"
+verify "$3"
+
# User may have a custom install script
if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
--
2.30.2
^ permalink raw reply related
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