On Mon, Sep 08, 2025 at 04:33:24PM +0530, Naveen N Rao wrote:
> On Wed, Sep 03, 2025 at 10:37:39PM -0400, Joe Lawrence wrote:
> > On Wed, Sep 03, 2025 at 10:29:50PM -0400, Joe Lawrence wrote:
> > > The powerpc64 module .stubs section holds ppc64_stub_entry[] code
> >
ftrace records are consistent
before being handled by the ftrace core.
Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line")
Suggested-by: Naveen N Rao
Signed-off-by: Joe Lawrence
---
arch/powerpc/kernel/trace/ftrace.c | 10 --
1 file changed, 8 insert
ary for the next free slot.
This simplifies the allocation code, hardens it against future changes
to stub structures, and removes the need for an extra relocation slot
previously reserved to terminate the sentinel search.
Signed-off-by: Joe Lawrence
---
arch/powerpc/include/asm/module.h |
msg on cleanup patch [Naveen]
Joe Lawrence (3):
powerpc/ftrace: ensure ftrace record ops are always set for NOPs
powerpc64/modules: correctly iterate over stubs in
setup_ftrace_ool_stubs
powerpc64/modules: replace stub allocation sentinel with an explicit
counter
arch/powerpc/inclu
first entry.
Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line")
Signed-off-by: Joe Lawrence
---
arch/powerpc/kernel/module_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_
On Wed, Sep 03, 2025 at 10:29:50PM -0400, Joe Lawrence wrote:
> The powerpc64 module .stubs section holds ppc64_stub_entry[] code
> trampolines that are generated at module load time. These stubs are
> necessary for function calls to external symbols that are too far away
> for a sim
64/ftrace: Move ftrace sequence out of line")
Signed-off-by: Joe Lawrence
---
arch/powerpc/include/asm/module.h | 1 +
arch/powerpc/kernel/module_64.c | 26 --
2 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/module.h
b/arch
il
>
> # To debug, uncomment the following line
> # set -x
> diff --git a/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
> b/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
> index 73e331e7660e..6193b0ed0c77 100755
> --- a/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
> +++
On 1/16/25 04:29, Petr Mladek wrote:
> On Tue 2025-01-14 20:01:44, Madhavan Srinivasan wrote:
>> Some arch configs (like ppc64) enable CONFIG_PRINTK_CALLER, which
>> adds the caller id as part of the dmesg. Due to this, even though
>> the expected vs observed are same, end testcase results are fail
_dmesg {
> p=1 }' | \
>grep -e 'livepatch:' -e 'test_klp' | \
>grep -v '\(tainting\|taints\) kernel' | \
> - sed 's/^\[[ 0-9.]*\] //')
> + sed 's/^\[[ 0-9.]*\] //
On 8/15/24 12:07, Ryan Sullivan wrote:
> Hi Michael,
>
> The r2 value is stored to the livepatch stack prior to entering into
> the livepatched code, so accessing it will gurantee the previous value
> is restored.
>
> Also, yes, this bug is caused by tooling that "scoops out" pre-compiled
> code
backchain is no longer true, since
> commit edbd0387f324 ("powerpc: copy_thread add a back chain to the
> switch stack frame"), so remove that as well.
>
> Reported-by: Joe Lawrence
> Signed-off-by: Michael Ellerman
> Fixes: eed7c420aac7 ("powerpc: copy_thread di
On 9/21/23 08:26, Michael Ellerman wrote:
> Petr Mladek writes:
>> On Wed 2023-08-30 17:47:35, Joe Lawrence wrote:
>>> On 8/30/23 02:37, Michael Ellerman wrote:
>>>> Michael Ellerman writes:
>>>>> Joe Lawrence writes:
>>>>>>
On 8/30/23 02:37, Michael Ellerman wrote:
> Michael Ellerman writes:
>> Joe Lawrence writes:
>>> Hi ppc-dev list,
>>>
>>> We noticed that our kpatch integration tests started failing on ppc64le
>>> when targeting the upstream v6.4 kernel, and the
Hi ppc-dev list,
We noticed that our kpatch integration tests started failing on ppc64le
when targeting the upstream v6.4 kernel, and then confirmed that the
in-tree livepatching kselftests similarly fail, too. From the kselftest
results, it appears that livepatch transitions are no longer comple
ions(+), 11 deletions(-)
>
> --
> 2.39.0
>
For the series,
Reviewed-and-tested-by: Joe Lawrence
--
Joe
On 12/13/22 8:29 AM, Petr Mladek wrote:
> On Tue 2022-12-13 00:13:46, Song Liu wrote:
>> )() ()On Mon, Dec 12, 2022 at 9:12 AM Petr Mladek wrote:
>>>
>>> On Fri 2022-12-09 11:59:35, Song Liu wrote:
On Fri, Dec 9, 2022 at 3:41 AM Petr Mladek wrote:
> On Mon 2022-11-28 17:57:06, Song Liu w
On 11/18/22 12:14 PM, Song Liu wrote:
> Hi Petr,
>
> On Fri, Nov 18, 2022 at 8:24 AM Petr Mladek wrote:
>>
>> On Thu 2022-09-01 10:12:52, Song Liu wrote:
> [...]
>>>
>>> arch/powerpc/kernel/module_32.c | 10
>>> arch/powerpc/kernel/module_64.c | 49 +++
>>> arch/s390/kernel/mo
On Thu, Sep 01, 2022 at 01:39:02PM +1000, Michael Ellerman wrote:
> Joe Lawrence writes:
> > On Thu, Sep 01, 2022 at 08:30:44AM +1000, Michael Ellerman wrote:
> >> Joe Lawrence writes:
> ...
> >
> > Hi Michael,
> >
> > While we're on the t
On Thu, Sep 01, 2022 at 08:30:44AM +1000, Michael Ellerman wrote:
> Joe Lawrence writes:
> > On Tue, Aug 30, 2022 at 11:53:13AM -0700, Song Liu wrote:
> >> From: Miroslav Benes
> >>
> >> Josh reported a bug:
> >>
> >> When th
On Wed, Aug 31, 2022 at 03:48:26PM -0700, Song Liu wrote:
> On Wed, Aug 31, 2022 at 3:30 PM Michael Ellerman wrote:
> >
> > Joe Lawrence writes:
> > > On Tue, Aug 30, 2022 at 11:53:13AM -0700, Song Liu wrote:
> > >> From: Miroslav Benes
> > >>
ate_add(Elf_Shdr *sechdrs,
> >unsigned int relsec,
> >struct module *mod);
> > #ifdef CONFIG_LIVEPATCH
> > -void clear_relocate_add(Elf64_Shdr *sechdrs,
> > +void clear_relocate_add(Elf_Shdr *sechdrs,
> >
d0
GPR24: 72d1b830 72d1efbb 010005bf02a0
GPR28: 72d1be50 010005bf1810 0010
NIP [7fffa178fb6c] 0x7fffa178fb6c
LR [] 0x0
--- interrupt: 3000
Instruction dump:
40820044 813b002c 7ff5f82a 79293664 7d394a14 e9290010 7c69f82e 7fe9fa14
48052235 6000 2c03 41820008 <92ff0004> eadb0020 6000 6000
---[ end trace ]---
$ addr2line 0xc005659c -e vmlinux
/root/klp-convert-tree/arch/powerpc/kernel/module_64.c:785
743 void clear_relocate_add(Elf64_Shdr *sechdrs,
744const char *strtab,
745unsigned int symindex,
746unsigned int relsec,
747struct module *me)
748 {
...
759 for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rela); i++) {
...
785 *instruction = PPC_RAW_NOP();
786 }
$ readelf --wide --sections test_klp_convert1.ko | grep -e '\[ 6\]' -e '\[48\]'
[ 6] .text.unlikely PROGBITS
0001b8 0001cc 00 AX 0 0 4
[48] .klp.rela.test_klp_convert_mod..text.unlikely RELA
041358 30 18 Ao 45 6 8
$ readelf --wide --relocs test_klp_convert1.ko
...
Relocation section '.klp.rela.test_klp_convert_mod..text.unlikely' at offset
0x41358 contains 2 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
00f0 0049000a R_PPC64_REL24
.klp.sym.test_klp_convert_mod.test_klp_get_driver_name,0 + 0
0158 0045000a R_PPC64_REL24
.klp.sym.test_klp_convert_mod.get_homonym_string,1 + 0
PS - I will be OOTO for a few weeks in Sept
[1]
https://github.com/joe-lawrence/klp-convert-tree/tree/klp-convert-v7-devel+song
-- Joe
On Thu, Jan 27, 2022 at 11:42:49AM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> First S390 complained that the sorting of the mcount sections at build
> time caused the kernel to crash on their architecture. Now PowerPC is
> complaining about it too. And also ARM64 appears to
| ((value - (uint32_t)location)
> & 0x03fc);
> +
> + if (patch_instruction(location, ppc_inst(value)))
> + return -EFAULT;
> +
> pr_debug("Location after: %08X.\n",
> *(uint32_t *)location);
> pr_debug("ie. jump to %08X+%08X = %08X\n",
> --
> 2.33.1
>
IIRC, offlist we hacked up klp-convert to create the klp-relocations for
a 32-bit target and then you hit the selftest late relocation crash, so
I assume that part is happy after this fix. :) Thanks again for the
testing.
For the livepatching implications,
Acked-by: Joe Lawrence
-- Joe
On 12/14/21 7:44 AM, Christophe Leroy wrote:
>
>
> Le 13/12/2021 à 18:26, Joe Lawrence a écrit :
>> On 12/13/21 11:36 AM, Christophe Leroy wrote:
>>>
>>>
>>> Le 13/12/2021 à 15:47, Joe Lawrence a écrit :
>>>> On 12/13/21 2:42 AM, Christop
On 12/13/21 11:36 AM, Christophe Leroy wrote:
>
>
> Le 13/12/2021 à 15:47, Joe Lawrence a écrit :
>> On 12/13/21 2:42 AM, Christophe Leroy wrote:
>>>
>>> Hello Joe,
>>>
>>> I'm implementing LIVEPATCH on PPC32 and I wanted to test wit
On 12/13/21 2:42 AM, Christophe Leroy wrote:
>
> Hello Joe,
>
> I'm implementing LIVEPATCH on PPC32 and I wanted to test with
> STRICT_MODULE_RWX enabled so I took your branch as suggested, but I'm
> getting the following errors on build. What shall I do ?
>
>CALLscripts/checksyscalls.
On 12/9/21 2:00 AM, Michael Ellerman wrote:
> Russell Currey writes:
>> On Tue, 2021-12-07 at 09:44 -0500, Joe Lawrence wrote:
>>> On 11/23/21 3:15 AM, Russell Currey wrote:
>>>
>>> [[ cc += livepatching list ]]
>>>
>>> Hi Russell,
>>>
ion & ~0x03fc)
> + value = (*(uint32_t *)location & ~0x03fc)
> | (value & 0x03fc);
> + patch_instruction((u32 *)location, ppc_inst(value));
> break;
>
>
On 11/1/21 5:20 AM, Russell Currey wrote:
> I'm looking into this now, will update when there's progress. I
> personally wasn't aware but Jordan flagged this as an issue back in
> August [0]. Are the selftests in the klp-convert tree sufficient for
> testing? I'm not especially familiar with liv
rnel.org/lkml/cover.1588173720.git.jpoim...@redhat.com/
[4] https://github.com/dynup/kpatch/issues/1228
[5]
https://github.com/joe-lawrence/linux/tree/klp-convert-v5-expanded-v5.14-rebase1
, we
might as well finally remove it from the codebase.
Link: https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204430.html
Link: https://lore.kernel.org/lkml/1108002773.7733.196.camel@gaston/
Signed-off-by: Joe Lawrence
---
arch/powerpc/include/asm/vdso.h | 24
On 2/24/20 5:17 AM, Benjamin Herrenschmidt wrote:
On Sat, 2020-02-22 at 18:07 -0600, Segher Boessenkool wrote:
so I don't believe they are ever used by default -- in this case
V_FUNCTION_BEGIN doesn't add to the .opd section with .name, .TOC base,
etc.
Manually setting VDS64_HAS_DESCRIPTORS re
I was wondering if there was history behind VDS64_HAS_DESCRIPTORS and in
what cases would one want to turn them on? (Note, I'm assuming they are
an implementation of Function Descriptors. [1])
arch/powerpc/include/asm/vdso.h unsets the macro:
/* Define if 64 bits VDSO has procedure descriptors
On 3/28/19 8:57 AM, Masahiro Yamada wrote:
Hi Joe,
OK, confirmed.
>
> [ ... snip ]
First, I was wondering why I could not reproduce this issue.
Then, I found the reason was I was using the latest GNU Make
compiled from the git source tree.
I found the following commit:
commit b90fabc8d
On Tue, Mar 26, 2019 at 02:29:47PM +0900, Masahiro Yamada wrote:
> On Tue, Mar 26, 2019 at 1:05 AM Joe Lawrence wrote:
> >
> > CC_FLAGS_FTRACE may contain trailing whitespace that interferes with
> > findstring.
> >
> > For example, commit 6977f95e63b9 (&qu
On 3/23/19 1:27 PM, Joe Lawrence wrote:
On 03/23/2019 12:17 PM, Steven Rostedt wrote:
On Sat, 23 Mar 2019 09:19:50 -0400
Joe Lawrence wrote:
Perhaps this is gcc version specific? I didn't see any other reports,
so maybe its specific to my config. If I run make V=1, I can see that
g
findstring is looking for this extra space
Remove the redundant whitespaces from CC_FLAGS_FTRACE in
cmd_record_mcount to avoid this problem.
Fixes: 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on GCC 4.9 and newer").
Signed-off-by: Joe Lawrence
---
Standard disclaimer: I'm n
On 03/23/2019 12:17 PM, Steven Rostedt wrote:
On Sat, 23 Mar 2019 09:19:50 -0400
Joe Lawrence wrote:
Perhaps this is gcc version specific? I didn't see any other reports,
so maybe its specific to my config. If I run make V=1, I can see that
gcc is called with '-pg -mprofile-ke
On Sat, Mar 23, 2019 at 12:17:32PM -0400, Steven Rostedt wrote:
> On Sat, 23 Mar 2019 09:19:50 -0400
> Joe Lawrence wrote:
>
> > Perhaps this is gcc version specific? I didn't see any other reports,
> > so maybe its specific to my config. If I run make V=1, I can
Hi Steve, Nicholas,
I stumbled across this while working on livepatch self-tests, which like
the ftrace self-tests, specify $(CC_FLAGS_FTRACE) to ensure that target
functions are indeed trace-able.
On ppc64le, v5.0 fails the self-tests on my machine:
% gcc --version
gcc (GCC) 8.2.1 20180905
As tglx points out, there are no in-tree module users of
save_stack_trace_tsk_reliable() and its x86 counterpart is not exported,
so remove the powerpc symbol export.
Suggested-by: Thomas Gleixner
Signed-off-by: Joe Lawrence
---
arch/powerpc/kernel/stacktrace.c | 1 -
1 file changed, 1
To match its x86 counterpart, save_stack_trace_tsk_reliable() should
return -EINVAL in cases that it is currently returning 1. No caller is
currently differentiating non-zero error codes, but let's keep the
arch-specific implementations consistent.
Signed-off-by: Joe Lawrence
---
arch/po
Mostly cosmetic changes:
- Group common stack pointer code at the top
- Simplify the first frame logic
- Code stackframe iteration into for...loop construct
- Check for trace->nr_entries overflow before adding any into the array
Suggested-by: Nicolai Stange
Signed-off-by: Joe Lawre
R_SAVE and STACK_FRAME_MARKER offsets that
may contain uninitialized residual data.
Fixes: df78d3f61480 ("powerpc/livepatch: Implement reliable stack tracing for
the consistency model")
Signed-off-by: Joe Lawrence
---
arch/powerpc/kernel/stacktrace.c | 32
RKER magic,
as written by exception prologues, is found at a particular location.
However, as observed by Joe Lawrence, it is possible in practice that
non-exception stack frames can alias with prior exception frames and thus,
that the reliable stacktracer can find a stale STACK_FRAME_REGS_MAR
https://lore.kernel.org/lkml/7f468285-b149-37e2-e782-c9e538b99...@redhat.com/
Joe Lawrence (3):
powerpc/livepatch: relax reliable stack tracer checks for first-frame
powerpc/livepatch: small cleanups in save_stack_trace_tsk_reliable()
powerpc/livepatch: return -ERRNO valu
On 1/14/19 12:09 PM, Josh Poimboeuf wrote:
On Mon, Jan 14, 2019 at 11:46:59AM -0500, Joe Lawrence wrote:
@@ -158,11 +158,21 @@ save_stack_trace_tsk_reliable(struct task_struct *tsk,
return 1; /* invalid backlink, too far up. */
}
+ /* We can only
On Mon, Jan 14, 2019 at 08:21:40AM +0100, Nicolai Stange wrote:
> Joe Lawrence writes:
>
> > We should be careful when inspecting the bottom-most stack frame (the
> > first to be unwound), particularly for scheduled-out tasks. As Nicolai
> > Stange explains, "If I&
On Fri, Jan 11, 2019 at 08:51:54AM +0100, Nicolai Stange wrote:
> Joe Lawrence writes:
>
> > On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
[ ... snip ... ]
> >> For testing, could you try whether clearing the word at STACK_FRAME_MARKER
>
On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
> Hi Joe,
>
> Joe Lawrence writes:
>
> > tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
> >about?
>
> If I'm reading the code in _switch() correctly, the first
Hi all,
tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
about?
I am looking at a bug in which ~10% of livepatch tests on RHEL-7 and
RHEL-8 distro kernels, the ppc64le reliable stack unwinder consistently
reports an unreliable stack for a given task. This condition can
53 matches
Mail list logo
