Re: [RFC PATCH v1 1/3] Revert "powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm goto"

Christophe Leroy wrote: This reverts commit 1e688dd2a3d6759d416616ff07afc4bb836c4213. That commit aimed at optimising the code around generation of WARN_ON/BUG_ON but this leads to a lot of dead code erroneously generated by GCC. text data bss dec hex filename

[powerpc:next] BUILD SUCCESS b684c09f09e7a6af3794d4233ef785819e72db79

built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc alpharandconfig-r001-20230619 gcc alpharandconfig-r004-20230619 gcc

[PATCH 2/2] powerpc: drop MPC85xx_CDS platform support

The MPC8541/8548/8555 Configurable Development System (CDS) were the vehicle used to provide evaluation of the 1st e500-v2 CPUs around 2007. Similar to the earlier MPC83xx-MDS systems we removed, the "brains" exist on a PCI-X card, but additional connectors exist to the right of the PCI-X slot,

[PATCH 1/2] powerpc: drop MPC8540_ADS and MPC8560_ADS platform support

Based on the revision history in the manual(s), these e500-v1 platforms were first available around 2002. Like a lot of evaluation boards, they attempted to provide break-out connectors for all possible features, and that combined with four PCI-X slots (and the age/era) meant for a considerably

[PATCH v2 0/2] Remove some e500/MPC85xx evaluation platforms

v1: https://lore.kernel.org/all/20230221194637.28436-1-paul.gortma...@windriver.com/ v1 --> v2: -don't remove MPC8568MDS or P1021 or P1012 platforms as per discussion -drop commit #4 that removed kernel fragments still in use elsewhere. -trivial refresh for the updated baseline of

Re: [PATCH mm-unstable v2 00/10] mm/kvm: locklessly clear the accessed bit

On Fri, Jun 9, 2023 at 3:08 AM Paolo Bonzini wrote: > > On 5/27/23 01:44, Yu Zhao wrote: > > TLDR > > > > This patchset adds a fast path to clear the accessed bit without > > taking kvm->mmu_lock. It can significantly improve the performance of > > guests when the host is under heavy memory

Re: [PATCH v2 13/13] sh/kexec: refactor for kernel/Kconfig.kexec

Hi Eric! On Mon, 2023-06-19 at 10:58 -0400, Eric DeVolder wrote: > The kexec and crash kernel options are provided in the common > kernel/Kconfig.kexec. Utilize the common options and provide > the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the > equivalent set of KEXEC and CRASH

[PATCH v2 11/13] riscv/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Signed-off-by: Eric DeVolder --- arch/riscv/Kconfig | 48

[PATCH v2 06/13] loongarch/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Signed-off-by: Eric DeVolder --- arch/loongarch/Kconfig | 26

[PATCH v2 13/13] sh/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Signed-off-by: Eric DeVolder --- arch/sh/Kconfig | 46

[PATCH v2 12/13] s390/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. NOTE: The original Kconfig has a KEXEC_SIG which depends on

[PATCH v2 03/13] arm/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Signed-off-by: Eric DeVolder --- arch/arm/Kconfig | 29

[PATCH v2 10/13] powerpc/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Signed-off-by: Eric DeVolder Reviewed-by: Sourabh Jain ---

[PATCH v2 04/13] ia64/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Signed-off-by: Eric DeVolder --- arch/ia64/Kconfig | 28

[PATCH v2 08/13] mips/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Signed-off-by: Eric DeVolder --- arch/mips/Kconfig | 32

[PATCH v2 09/13] parisc/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Signed-off-by: Eric DeVolder --- arch/parisc/Kconfig | 34

[PATCH v2 05/13] arm64/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Signed-off-by: Eric DeVolder --- arch/arm64/Kconfig | 62

[PATCH v2 07/13] m68k/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Signed-off-by: Eric DeVolder Reviewed-by: Geert Uytterhoeven

[PATCH v2 00/13] refactor Kconfig to consolidate KEXEC and CRASH options

The Kconfig is refactored to consolidate KEXEC and CRASH options from various arch//Kconfig files into new file kernel/Kconfig.kexec. The Kconfig.kexec is now a submenu titled "Kexec and crash features" located under "General Setup". The following options are impacted: - KEXEC - KEXEC_FILE -

[PATCH v2 02/13] x86/kexec: refactor for kernel/Kconfig.kexec

The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Signed-off-by: Eric DeVolder --- arch/x86/Kconfig | 89

[PATCH v2 01/13] kexec: consolidate kexec and crash options into kernel/Kconfig.kexec

The config options for kexec and crash features are consolidated into new file kernel/Kconfig.kexec. Under the "General Setup" submenu is a new submenu "Kexec and crash handling" where all the kexec and crash options that were once in the arch-dependent submenu "Processor type and features" are

Re: [PATCH] ASoC: imx-audmix: check return value of devm_kasprintf()

On Wed, 14 Jun 2023 15:15:09 +0300, Claudiu Beznea wrote: > devm_kasprintf() returns a pointer to dynamically allocated memory. > Pointer could be NULL in case allocation fails. Check pointer validity. > Identified with coccinelle (kmerr.cocci script). > > Applied to

Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc()

> On Jun 19, 2023, at 10:09 AM, Andy Lutomirski wrote: > > But jit_text_alloc() can't do this, because the order of operations doesn't > match. With jit_text_alloc(), the executable mapping shows up before the > text is populated, so there is no atomic change from not-there to >

Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc()

On Sun, Jun 18, 2023, at 1:00 AM, Mike Rapoport wrote: > On Sat, Jun 17, 2023 at 01:38:29PM -0700, Andy Lutomirski wrote: >> On Fri, Jun 16, 2023, at 1:50 AM, Mike Rapoport wrote: >> > From: "Mike Rapoport (IBM)" >> > >> > module_alloc() is used everywhere as a mean to allocate memory for

Re: [PATCH v2 2/2] powerpc/mm: Add memory_block_size as a kernel parameter

On 19.06.23 18:17, Aneesh Kumar K.V wrote: David Hildenbrand writes: On 09.06.23 08:08, Aneesh Kumar K.V wrote: Certain devices can possess non-standard memory capacities, not constrained to multiples of 1GB. Provide a kernel parameter so that we can map the device memory completely on

Re: [PATCH v2 2/2] powerpc/mm: Add memory_block_size as a kernel parameter

David Hildenbrand writes: > On 09.06.23 08:08, Aneesh Kumar K.V wrote: >> Certain devices can possess non-standard memory capacities, not constrained >> to multiples of 1GB. Provide a kernel parameter so that we can map the >> device memory completely on memory hotplug. > > So, the unfortunate

Re: [PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc()

On Mon, Jun 19, 2023 at 12:32:55AM +0200, Thomas Gleixner wrote: > Mike! > > Sorry for being late on this ... > > On Fri, Jun 16 2023 at 11:50, Mike Rapoport wrote: > > The fact that my suggestions had a 'mod_' namespace prefix does not make > any of my points moot. The prefix does not matter.

Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc()

On Sat, Jun 17, 2023 at 01:38:29PM -0700, Andy Lutomirski wrote: > On Fri, Jun 16, 2023, at 1:50 AM, Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > > > module_alloc() is used everywhere as a mean to allocate memory for code. > > > > Beside being semantically wrong, this unnecessarily

Re: [PATCH v2 2/2] powerpc/mm: Add memory_block_size as a kernel parameter

On 09.06.23 08:08, Aneesh Kumar K.V wrote: Certain devices can possess non-standard memory capacities, not constrained to multiples of 1GB. Provide a kernel parameter so that we can map the device memory completely on memory hotplug. So, the unfortunate thing is that these devices would have

Re: [PATCH v2 4/6] watchdog/hardlockup: Make HAVE_NMI_WATCHDOG sparc64-specific

On Fri 2023-06-16 09:48:06, Doug Anderson wrote: > Hi, > > On Fri, Jun 16, 2023 at 8:07 AM Petr Mladek wrote: > > > > There are several hardlockup detector implementations and several Kconfig > > values which allow selection and build of the preferred one. [...] > > Note that

[PATCH 04/17] powerpc/ftrace: Simplify function_graph support in ftrace.c

Since we now support DYNAMIC_FTRACE_WITH_ARGS across ppc32 and ppc64 ELFv2, we can simplify function_graph tracer support code in ftrace.c Signed-off-by: Naveen N Rao --- arch/powerpc/kernel/trace/ftrace.c | 64 -- 1 file changed, 7 insertions(+), 57 deletions(-)

[PATCH 13/17] powerpc/ftrace: Simplify ftrace_modify_call()

Now that we validate the ftrace location during initialization in ftrace_init_nop(), we can simplify ftrace_modify_call() to patch-in the updated branch instruction without worrying about the instructions surrounding the ftrace location. Note that we continue to ensure we have the expected branch

[PATCH 12/17] powerpc/ftrace: Simplify ftrace_make_call()

Now that we validate the ftrace location during initialization in ftrace_init_nop(), we can simplify ftrace_make_call() to replace the nop without worrying about the instructions surrounding the ftrace location. Note that we continue to ensure that we have a nop at the ftrace location before

[PATCH 11/17] powerpc/ftrace: Simplify ftrace_make_nop()

Now that we validate the ftrace location during initialization in ftrace_init_nop(), we can simplify ftrace_make_nop() to patch-in the nop without worrying about the instructions surrounding the ftrace location. Note that we continue to ensure that we have a bl to ftrace_[regs_]caller at the

[PATCH 10/17] powerpc/ftrace: Add separate ftrace_init_nop() with additional validation

Currently, we validate instructions around the ftrace location every time we have to enable/disable ftrace. Introduce ftrace_init_nop() to instead perform all the validation during ftrace initialization. This allows us to simply patch the necessary instructions during enabling/disabling ftrace.

[PATCH 09/17] powerpc/ftrace: Stop re-purposing linker generated long branches for ftrace

Commit 67361cf8071286 ("powerpc/ftrace: Handle large kernel configs") added ftrace support for ppc64 kernel images with a text section larger than 32MB. The patch did two things: 1. Add stubs at the end of .text to branch into ftrace_[regs_]caller for functions that were out of branch range. 2.

[PATCH 08/17] powerpc/ftrace: Refactor ftrace_modify_code()

Split up ftrace_modify_code() into a few helpers for future use. Also update error messages accordingly. Signed-off-by: Naveen N Rao --- arch/powerpc/kernel/trace/ftrace.c | 51 +- 1 file changed, 29 insertions(+), 22 deletions(-) diff --git

[PATCH 07/17] powerpc/ftrace: Consolidate ftrace support into fewer files

ftrace_low.S has just the _mcount stub and return_to_handler(). Merge this back into ftrace_mprofile.S and ftrace_64_pg.S to keep all ftrace code together, and to allow those to evolve independently. ftrace_mprofile.S is also not an entirely accurate name since this also holds ppc32 code. This

[PATCH 06/17] powerpc/ftrace: Extend ftrace support for large kernels to ppc32

Commit 67361cf8071286 ("powerpc/ftrace: Handle large kernel configs") added ftrace support for ppc64 kernel images with a text section larger than 32MB. The approach itself isn't specific to ppc64, so extend the same to also work on ppc32. While at it, reduce the space reserved for the stub from

[PATCH 05/17] powerpc/ftrace: Use FTRACE_REGS_ADDR to identify the correct ftrace trampoline

Instead of keying off DYNAMIC_FTRACE_WITH_REGS, use FTRACE_REGS_ADDR to identify the proper ftrace trampoline address to use. Signed-off-by: Naveen N Rao --- arch/powerpc/kernel/trace/ftrace.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git

[PATCH 17/17] powerpc/ftrace: Create a dummy stackframe to fix stack unwind

With ppc64 -mprofile-kernel and ppc32 -pg, profiling instructions to call into ftrace are emitted right at function entry. The instruction sequence used is minimal to reduce overhead. Crucially, a stackframe is not created for the function being traced. This breaks stack unwinding since the

[PATCH 16/17] powerpc/ftrace: Add support for -fpatchable-function-entry

GCC v13.1 updated support for -fpatchable-function-entry on ppc64le to emit nops after the local entry point, rather than before it. This allows us to use this in the kernel for ftrace purposes. A new script is added under arch/powerpc/tools/ to help detect if nops are emitted after the function

[PATCH 15/17] powerpc/ftrace: Implement ftrace_replace_code()

Implement ftrace_replace_code() to consolidate logic from the different ftrace patching routines: ftrace_make_nop(), ftrace_make_call() and ftrace_modify_call(). Note that ftrace_make_call() is still required primarily to handle patching modules during their load time. The other two routines

[PATCH 14/17] powerpc/ftrace: Replace use of ftrace_call_replace() with ftrace_create_branch_inst()

ftrace_create_branch_inst() is clearer about its intent than ftrace_call_replace(). Signed-off-by: Naveen N Rao --- arch/powerpc/kernel/trace/ftrace.c | 17 ++--- 1 file changed, 2 insertions(+), 15 deletions(-) diff --git a/arch/powerpc/kernel/trace/ftrace.c

[PATCH 01/17] powerpc/ftrace: Fix dropping weak symbols with older toolchains

The minimum level of gcc supported for building the kernel is v5.1. v5.x releases of gcc emitted a three instruction sequence for -mprofile-kernel: mflrr0 std r0, 16(r1) bl _mcount It is only with the v6.x releases that gcc started emitting the two instruction

[PATCH 03/17] powerpc64/ftrace: Move ELFv1 and -pg support code into a separate file

ELFv1 support is deprecated and on the way out. Pre -mprofile-kernel ftrace support (-pg only) is very limited and is retained primarily for clang builds. It won't be necessary once clang lands support for -fpatchable-function-entry. Copy the existing ftrace code supporting these into

[PATCH 02/17] powerpc/module: Remove unused .ftrace.tramp section

.ftrace.tramp section is not used for any purpose. This code was added all the way back in the original commit introducing support for dynamic ftrace on ppc64 modules. Remove it. Signed-off-by: Naveen N Rao --- arch/powerpc/include/asm/module.h | 4 1 file changed, 4 deletions(-) diff

[PATCH 00/17] powerpc/ftrace: refactor and add support for -fpatchable-function-entry

Since RFC (*): - Patches 1 and 17 have been included in this series due to dependencies. Both had been posted out separately. - Patch 10 has a small change to not throw errors when checking instruction sequence generated by older toolchains. This has had more testing since and this looks

next: arch/powerpc/kernel/stacktrace.c:171:9: error: implicit declaration of function 'nmi_cpu_backtrace'

Following build regressions noticed on Linux next-20230619. Reported-by: Linux Kernel Functional Testing Regressions found on powerpc: - build/clang-nightly-maple_defconfig - build/gcc-8-maple_defconfig - build/gcc-12-maple_defconfig - build/clang-nightly-cell_defconfig - build/gcc-12

[PATCH v3 1/1] powerpc: update ppc_save_regs to save current r1 in pt_regs

ppc_save_regs() skips one stack frame while saving the CPU register states. Instead of saving current R1, it pulls the previous stack frame pointer. When vmcores caused by direct panic call (such as `echo c > /proc/sysrq-trigger`), are debugged with gdb, gdb fails to show the backtrace correctly.