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:
>>>>>&g
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
insertions(+), 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
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 +++
>>>
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 topic
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
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
> > >>
PATCH
> > -void clear_relocate_add(Elf64_Shdr *sechdrs,
> > +void clear_relocate_add(Elf_Shdr *sechdrs,
> >const char *strtab,
> >unsigned int symindex,
> >unsigned int relsec,
> >
> >
> > But then
008 <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
> & 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 with
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 ?
>
>CALL
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,
>>>
uint32_t *)location & ~0x03fc)
> | (value & 0x03fc);
> + patch_instruction((u32 *)location, ppc_inst(value));
> break;
>
> case R_PPC64_REL64:
>
[[ cc += livepatching list
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
kml/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
nally 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
arch/powerpc/kernel/vdso.
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
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
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
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 (
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
gcc
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 not a
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-kernel
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 see t
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/powerpc
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
ME_LR_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_R
://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 values
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 frame
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
42 matches
Mail list logo
