Re: [PATCH bpf-next] bpf: Change value of MAX_TAIL_CALL_CNT from 32 to 33

On Wed, Sep 8, 2021 at 8:33 PM Tiezhu Yang 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

[PATCH bpf-next] bpf: Change value of MAX_TAIL_CALL_CNT from 32 to 33

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. We can see the

Re: [PATCH 1/2] powerpc/perf: Expose instruction and data address registers as part of extended regs

> On 08-Sep-2021, at 10:47 AM, Michael Ellerman wrote: > > Athira Rajeev writes: >> Patch adds support to include Sampled Instruction Address Register >> (SIAR) and Sampled Data Address Register (SDAR) SPRs as part of extended >> registers. Update the definition of PERF_REG_PMU_MASK_300/31

[PATCH v3 8/8] treewide: Replace the use of mem_encrypt_active() with cc_platform_has()

Replace uses of mem_encrypt_active() with calls to cc_platform_has() with the CC_ATTR_MEM_ENCRYPT attribute. Remove the implementation of mem_encrypt_active() across all arches. For s390, since the default implementation of the cc_platform_has() matches the s390 implementation of

[PATCH v3 7/8] x86/sev: Replace occurrences of sev_es_active() with cc_platform_has()

Replace uses of sev_es_active() with the more generic cc_platform_has() using CC_ATTR_GUEST_STATE_ENCRYPT. If future support is added for other memory encyrption techonologies, the use of CC_ATTR_GUEST_STATE_ENCRYPT can be updated, as required. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav

[PATCH v3 6/8] x86/sev: Replace occurrences of sev_active() with cc_platform_has()

Replace uses of sev_active() with the more generic cc_platform_has() using CC_ATTR_GUEST_MEM_ENCRYPT. If future support is added for other memory encryption technologies, the use of CC_ATTR_GUEST_MEM_ENCRYPT can be updated, as required. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov

[PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

Replace uses of sme_active() with the more generic cc_platform_has() using CC_ATTR_HOST_MEM_ENCRYPT. If future support is added for other memory encryption technologies, the use of CC_ATTR_HOST_MEM_ENCRYPT can be updated, as required. This also replaces two usages of sev_active() that are really

[PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

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 Cc: Benjamin Herrenschmidt Cc: Paul Mackerras

[PATCH v3 3/8] x86/sev: Add an x86 version of cc_platform_has()

Introduce an x86 version of the cc_platform_has() function. This will be used to replace vendor specific calls like sme_active(), sev_active(), etc. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Co-developed-by: Andi Kleen

[PATCH v3 2/8] mm: Introduce a function to check for confidential computing features

In prep for other confidential computing technologies, introduce a generic helper function, cc_platform_has(), that can be used to check for specific active confidential computing attributes, like memory encryption. This is intended to eliminate having to add multiple technology-specific checks to

[PATCH v3 1/8] x86/ioremap: Selectively build arch override encryption functions

In prep for other uses of the cc_platform_has() function besides AMD's memory encryption support, selectively build the AMD memory encryption architecture override functions only when CONFIG_AMD_MEM_ENCRYPT=y. These functions are: - early_memremap_pgprot_adjust() - arch_memremap_can_ram_remap()

[PATCH v3 0/8] Implement generic cc_platform_has() helper function

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

Re: [PATCH v2 3/5] signal: Add unsafe_copy_siginfo_to_user()

Christophe Leroy writes: > Le 02/09/2021 à 20:43, Eric W. Biederman a écrit : >> Christophe Leroy writes: >> >>> In the same spirit as commit fb05121fd6a2 ("signal: Add >>> unsafe_get_compat_sigset()"), implement an 'unsafe' version of >>> copy_siginfo_to_user() in order to use it within user

[Bug 213837] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5

https://bugzilla.kernel.org/show_bug.cgi?id=213837 --- Comment #6 from m...@ellerman.id.au --- bugzilla-dae...@bugzilla.kernel.org writes: > https://bugzilla.kernel.org/show_bug.cgi?id=213837 > > Erhard F. (erhar...@mailbox.org) changed: > >What|Removed |Added

Re: [Bug 213837] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5

bugzilla-dae...@bugzilla.kernel.org writes: > https://bugzilla.kernel.org/show_bug.cgi?id=213837 > > Erhard F. (erhar...@mailbox.org) changed: > >What|Removed |Added > >See

[RFC PATCH bpf-next] bpf: Make actual max tail call count as MAX_TAIL_CALL_CNT

In the current code, the actual max tail call count is 33 which is greater than MAX_TAIL_CALL_CNT, this is not consistent with the intended meaning in the commit 04fd61ab36ec ("bpf: allow bpf programs to tail-call other bpf programs"): "The chain of tail calls can form unpredictable dynamic loops

Re: [RFC PATCH v2] powerpc/papr_scm: Move duplicate definitions to common header files

Hi Mpe, Thanks for looking into this patch. Michael Ellerman writes: > Shivaprasad G Bhat writes: >> papr_scm and ndtest share common PDSM payload structs like >> nd_papr_pdsm_health. Presently these structs are duplicated across >> papr_pdsm.h >> and ndtest.h header files. Since 'ndtest' is

[PATCH v1 1/2] powerpc/64s: system call rfscv workaround for TM bugs

The rfscv instruction does not work correctly with the fake-suspend mode in POWER9, which can end up with the hypervisor restoring an incorrect checkpoint. Work around this by setting the _TIF_RESTOREALL flag if a system call returns to a transaction active state, causing rfid to be used instead

[PATCH v1 2/2] KVM: PPC: Book3S HV: Tolerate treclaim. in fake-suspend mode changing registers

POWER9 DD2.2 and 2.3 hardware implements a "fake-suspend" mode where certain TM instructions executed in HV=0 mode cause softpatch interrupts so the hypervisor can emulate them and prevent problematic processor conditions. In this fake-suspend mode, the treclaim. instruction does not modify

Re: [PATCH 1/3] perf: Add macros to specify onchip L2/L3 accesses

On Wed, Sep 08, 2021 at 05:17:53PM +1000, Michael Ellerman wrote: > Kajol Jain 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 > > +++

Re: [PATCH 0/5] s390/pci: automatic error recovery

On Wed, 2021-09-08 at 11:37 +1000, Oliver O'Halloran wrote: > On Tue, Sep 7, 2021 at 10:21 PM Niklas Schnelle > wrote: > > On Tue, 2021-09-07 at 10:45 +0200, Niklas Schnelle wrote: > > > On Tue, 2021-09-07 at 12:04 +1000, Oliver O'Halloran wrote: > > > > On Mon, Sep 6, 2021 at 7:49 PM Niklas

[PATCH 1/3] soc: mediatek: pwrap: Make use of the helper function devm_platform_ioremap_resource_byname()

Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing --- drivers/soc/mediatek/mtk-pmic-wrap.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git

[PATCH] soc: sunxi_sram: Make use of the helper function devm_platform_ioremap_resource()

Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing --- drivers/soc/sunxi/sunxi_sram.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/soc/sunxi/sunxi_sram.c

[PATCH] soc: ixp4xx/qmgr: Make use of the helper function devm_platform_ioremap_resource()

Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing --- drivers/soc/ixp4xx/ixp4xx-qmgr.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git

[PATCH 1/2] soc: bcm: bcm-pmb: Make use of the helper function devm_platform_ioremap_resource()

Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing --- drivers/soc/bcm/bcm63xx/bcm-pmb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH 1/2] soc: amlogic: canvas: Make use of the helper function devm_platform_ioremap_resource()

Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing --- drivers/soc/amlogic/meson-canvas.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH 1/2] soc: fsl: guts: Make use of the helper function devm_platform_ioremap_resource()

Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing --- drivers/soc/fsl/guts.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/soc/fsl/guts.c

Re: [PATCH 1/3] perf: Add macros to specify onchip L2/L3 accesses

Kajol Jain writes: > Add couple of new macros to represent onchip L2 and onchip L3 accesses. It would be "on chip". But I think this needs much more explanation, this is a generic header so these definitions need to make sense, and have an understood meaning, across all architectures. I think

[PATCH 2/2] soc: fsl: rcpm: Make use of the helper function devm_platform_ioremap_resource()

Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing --- drivers/soc/fsl/rcpm.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/soc/fsl/rcpm.c

[PATCH 1/2] soc: fsl: guts: Make use of the helper function devm_platform_ioremap_resource()

Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing --- drivers/soc/fsl/guts.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/soc/fsl/guts.c

Re: [PATCH] powerpc/mce: Fix access error in mce handler

On 9/8/21 11:10 AM, Michael Ellerman wrote: Ganesh writes: On 9/6/21 6:03 PM, Michael Ellerman wrote: Ganesh Goudar writes 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: GOE

Re: [PATCH kernel v2] KVM: PPC: Merge powerpc's debugfs entry content into generic entry

[hopefulle fixed my thunderbird now] Huh, not sure anymore after reading d56f5136b0102 "KVM: let kvm_destroy_vm_debugfs clean up vCPU debugfs directories" which remove debugfs_dentry from vcpu. Paolo? On 05/09/2021 12:27, Alexey Kardashevskiy wrote: Please ignore this one, v3 is coming.