Christophe Leroy wrote:
Le 20/06/2023 à 08:04, Naveen N Rao a écrit :
Christophe Leroy wrote:
A lot of work is required in .S files in order to get them ready
for objtool checks.
For the time being, exclude them from the checks.
This is done with the script below:
#!/bin/sh
DIRS=`f
On Sat May 27, 2023 at 9:44 AM AEST, Yu Zhao wrote:
> KVM page tables are currently not RCU safe against remapping, i.e.,
> kvmppc_unmap_free_pmd_entry_table() et al. The previous
Minor nit but the "page table" is not RCU-safe against something. It
is RCU-freed, and therefore some algorithm that a
Le 20/06/2023 à 08:04, Naveen N Rao a écrit :
> Christophe Leroy wrote:
>> A lot of work is required in .S files in order to get them ready
>> for objtool checks.
>>
>> For the time being, exclude them from the checks.
>>
>> This is done with the script below:
>>
>> #!/bin/sh
>> DIRS=`fin
Christophe Leroy wrote:
A lot of work is required in .S files in order to get them ready
for objtool checks.
For the time being, exclude them from the checks.
This is done with the script below:
#!/bin/sh
DIRS=`find arch/powerpc -name "*.S" -exec dirname {} \; | sort | uniq`
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
955158
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
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, tw
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 la
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 linux-
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 p
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 options
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
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 +++-
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 ---
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
MODULE_SIG_
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 --
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
---
arch/powe
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 +
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 +
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 +++
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 +---
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
Acked-by
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
-
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 +++---
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 now
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
https://git.kernel.org/p
> 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
> populated-
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 code.
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 memory
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 th
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.
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 tie
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 wo
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 HARDLOCKUP_DETECTOR_
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(-)
dif
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 i
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 patchi
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 ftrace
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.
Si
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.
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 a/arch/powerpc/kernel/tra
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 wil
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 6
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 a/arch/powerpc/kernel/trace/ftr
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 functio
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 lo
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 should
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
b/arch/powerpc/kernel/
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
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 ftrace_pg.c.
.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 --gi
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 goo
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
53 matches
Mail list logo
