On 2/27/25 10:47 PM, Indu Bhagat wrote:
On 2/27/25 1:38 AM, Puranjay Mohan wrote:
Indu Bhagat writes:
On 2/26/25 2:23 AM, Puranjay Mohan wrote:
Indu Bhagat writes:
On 2/25/25 3:54 PM, Weinan Liu wrote:
On Tue, Feb 25, 2025 at 11:38 AM Indu Bhagat
wrote:
On Mon, Feb 10, 2025 at 12:30 A
On 2/27/25 1:38 AM, Puranjay Mohan wrote:
Indu Bhagat writes:
On 2/26/25 2:23 AM, Puranjay Mohan wrote:
Indu Bhagat writes:
On 2/25/25 3:54 PM, Weinan Liu wrote:
On Tue, Feb 25, 2025 at 11:38 AM Indu Bhagat wrote:
On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu wrote:
I already have a WI
Indu Bhagat writes:
> On 2/26/25 2:23 AM, Puranjay Mohan wrote:
>> Indu Bhagat writes:
>>
>>> On 2/25/25 3:54 PM, Weinan Liu wrote:
On Tue, Feb 25, 2025 at 11:38 AM Indu Bhagat
wrote:
>
> On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu wrote:
>>> I already have a WIP patch
On 2/26/25 2:23 AM, Puranjay Mohan wrote:
Indu Bhagat writes:
On 2/25/25 3:54 PM, Weinan Liu wrote:
On Tue, Feb 25, 2025 at 11:38 AM Indu Bhagat wrote:
On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu wrote:
I already have a WIP patch to add sframe support to the kernel module.
However, it is
Indu Bhagat writes:
> On 2/25/25 3:54 PM, Weinan Liu wrote:
>> On Tue, Feb 25, 2025 at 11:38 AM Indu Bhagat wrote:
>>>
>>> On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu wrote:
> I already have a WIP patch to add sframe support to the kernel module.
> However, it is not yet working. I had
On 2/25/25 3:54 PM, Weinan Liu wrote:
On Tue, Feb 25, 2025 at 11:38 AM Indu Bhagat wrote:
On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu wrote:
I already have a WIP patch to add sframe support to the kernel module.
However, it is not yet working. I had trouble unwinding frames for the
kernel mo
On Tue, Feb 25, 2025 at 11:38 AM Indu Bhagat wrote:
>
> On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu wrote:
> >> I already have a WIP patch to add sframe support to the kernel module.
> >> However, it is not yet working. I had trouble unwinding frames for the
> >> kernel module using the current a
On Tue, Feb 25, 2025 at 10:13 AM Josh Poimboeuf wrote:
>
> On Tue, Feb 25, 2025 at 01:02:24AM +, Weinan Liu wrote:
> > On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu wrote:
> > > I already have a WIP patch to add sframe support to the kernel module.
> > > However, it is not yet working. I had tr
On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu wrote:
I already have a WIP patch to add sframe support to the kernel module.
However, it is not yet working. I had trouble unwinding frames for the
kernel module using the current algorithm.
Indu has likely identified the issue and will be addressing
On Tue, Feb 25, 2025 at 01:02:24AM +, Weinan Liu wrote:
> On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu wrote:
> > I already have a WIP patch to add sframe support to the kernel module.
> > However, it is not yet working. I had trouble unwinding frames for the
> > kernel module using the current
On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu wrote:
> I already have a WIP patch to add sframe support to the kernel module.
> However, it is not yet working. I had trouble unwinding frames for the
> kernel module using the current algorithm.
>
> Indu has likely identified the issue and will be add
On Thu, Feb 20, 2025 at 10:33 AM Song Liu wrote:
>
>
> On Thu, Feb 20, 2025 at 10:22 AM Josh Poimboeuf wrote:
>>
>> On Wed, Feb 19, 2025 at 08:50:09PM -0800, Song Liu wrote:
>> > Indu, is this behavior (symbols with same name are not in
>> > sorted order from readelf -s) expected? Or is this a bu
On Wed, Feb 19, 2025 at 08:50:09PM -0800, Song Liu wrote:
> Indu, is this behavior (symbols with same name are not in
> sorted order from readelf -s) expected? Or is this a bug?
> I am using this gcc:
>
> $ gcc --version
> gcc (GCC) 14.2.1 20240801 (Red Hat 14.2.1-1)
> Copyright (C) 2024 Free Soft
On Wed, Feb 19, 2025 at 9:44 AM Song Liu wrote:
>
> On Tue, Feb 18, 2025 at 10:41 AM Josh Poimboeuf wrote:
> >
> > On Tue, Feb 18, 2025 at 10:20:10AM -0800, Song Liu wrote:
> > > Hi Josh,
> > >
> > > On Mon, Feb 17, 2025 at 10:37 PM Josh Poimboeuf
> > > wrote:
> > > >
> > > > On Mon, Feb 17, 20
On Tue, Feb 18, 2025 at 10:41 AM Josh Poimboeuf wrote:
>
> On Tue, Feb 18, 2025 at 10:20:10AM -0800, Song Liu wrote:
> > Hi Josh,
> >
> > On Mon, Feb 17, 2025 at 10:37 PM Josh Poimboeuf wrote:
> > >
> > > On Mon, Feb 17, 2025 at 08:38:22PM -0800, Song Liu wrote:
> > > > On Fri, Feb 14, 2025 at 3:
On Tue, Feb 18, 2025 at 10:20:10AM -0800, Song Liu wrote:
> Hi Josh,
>
> On Mon, Feb 17, 2025 at 10:37 PM Josh Poimboeuf wrote:
> >
> > On Mon, Feb 17, 2025 at 08:38:22PM -0800, Song Liu wrote:
> > > On Fri, Feb 14, 2025 at 3:23 PM Josh Poimboeuf
> > > wrote:
> > > > Poking around the arm64 mod
Hi Josh,
On Mon, Feb 17, 2025 at 10:37 PM Josh Poimboeuf wrote:
>
> On Mon, Feb 17, 2025 at 08:38:22PM -0800, Song Liu wrote:
> > On Fri, Feb 14, 2025 at 3:23 PM Josh Poimboeuf wrote:
> > > Poking around the arm64 module code, arch/arm64/kernel/module-plts.c
> > > is looking at all the relocatio
On Mon, Feb 17, 2025 at 08:38:22PM -0800, Song Liu wrote:
> On Fri, Feb 14, 2025 at 3:23 PM Josh Poimboeuf wrote:
> > Poking around the arm64 module code, arch/arm64/kernel/module-plts.c
> > is looking at all the relocations in order to set up the PLT. That also
> > needs to be done for klp relas
On Fri, Feb 14, 2025 at 3:23 PM Josh Poimboeuf wrote:
>
> On Fri, Feb 14, 2025 at 02:04:17PM -0800, Song Liu wrote:
> > Hi Josh,
> >
> > On Fri, Feb 14, 2025 at 11:34 AM Josh Poimboeuf wrote:
> > >
> > > On Fri, Feb 14, 2025 at 09:51:41AM -0800, Song Liu wrote:
> > > > > Ignorant arm64 question:
On Fri, Feb 14, 2025 at 02:04:17PM -0800, Song Liu wrote:
> Hi Josh,
>
> On Fri, Feb 14, 2025 at 11:34 AM Josh Poimboeuf wrote:
> >
> > On Fri, Feb 14, 2025 at 09:51:41AM -0800, Song Liu wrote:
> > > > Ignorant arm64 question: is the module's text further away from slab
> > > > memory than vmlinu
On Fri, Feb 14, 2025 at 02:04:17PM -0800, Song Liu wrote:
> Hi Josh,
>
> On Fri, Feb 14, 2025 at 11:34 AM Josh Poimboeuf wrote:
> >
> > On Fri, Feb 14, 2025 at 09:51:41AM -0800, Song Liu wrote:
> > > > Ignorant arm64 question: is the module's text further away from slab
> > > > memory than vmlinu
Hi Josh,
On Fri, Feb 14, 2025 at 11:34 AM Josh Poimboeuf wrote:
>
> On Fri, Feb 14, 2025 at 09:51:41AM -0800, Song Liu wrote:
> > > Ignorant arm64 question: is the module's text further away from slab
> > > memory than vmlinux text, thus requiring a different instruction (or
> > > GOT/TOC) to acc
On Fri, Feb 14, 2025 at 11:38:22AM -0800, Josh Poimboeuf wrote:
> On Fri, Feb 14, 2025 at 06:58:01PM +, Puranjay Mohan wrote:
> > and the linker script has this line:
> >
> > .sframe : AT(ADDR(.sframe) - 0) { __start_sframe_header = .;
> > KEEP(*(.sframe)) __stop_sframe_header = .; }
> >
> >
On Fri, Feb 14, 2025 at 06:58:01PM +, Puranjay Mohan wrote:
> and the linker script has this line:
>
> .sframe : AT(ADDR(.sframe) - 0) { __start_sframe_header = .; KEEP(*(.sframe))
> __stop_sframe_header = .; }
>
> So, do can you suggest the best way to fix these warnings?
Just add *(.init.
On Fri, Feb 14, 2025 at 09:51:41AM -0800, Song Liu wrote:
> > Ignorant arm64 question: is the module's text further away from slab
> > memory than vmlinux text, thus requiring a different instruction (or
> > GOT/TOC) to access memory further away in the address space?
>
> It appears to me the modu
Indu Bhagat writes:
> On 2/14/25 9:39 AM, Indu Bhagat wrote:
>> On 2/13/25 11:57 PM, Puranjay Mohan wrote:
>>> Indu Bhagat writes:
>>>
On 2/12/25 11:25 PM, Song Liu wrote:
> On Wed, Feb 12, 2025 at 6:45 PM Josh Poimboeuf
> wrote:
>>
>> On Wed, Feb 12, 2025 at 06:36:04PM -0
On 2/14/25 9:39 AM, Indu Bhagat wrote:
On 2/13/25 11:57 PM, Puranjay Mohan wrote:
Indu Bhagat writes:
On 2/12/25 11:25 PM, Song Liu wrote:
On Wed, Feb 12, 2025 at 6:45 PM Josh Poimboeuf
wrote:
On Wed, Feb 12, 2025 at 06:36:04PM -0800, Song Liu wrote:
[ 81.261748] copy_process+0xfdc/0xf
On Fri, Feb 14, 2025 at 08:56:45AM +, Puranjay Mohan wrote:
> I did this test and found the same issue as you (gdb assembly broken),
> but I can see this issue even without the inlining. I think GDB tried to
> load the debuginfo and that is somehow broken therefore it fails to
> disassemblt pro
Hi Puranjay,
Thanks for running the tests.
On Fri, Feb 14, 2025 at 12:56 AM Puranjay Mohan wrote:
[...]
> >
> > I am really curious whether you have the same problem in your
> > setup.
>
> Hi Song,
>
> I did this test and found the same issue as you (gdb assembly broken),
> but I can see this is
On 2/13/25 11:57 PM, Puranjay Mohan wrote:
Indu Bhagat writes:
On 2/12/25 11:25 PM, Song Liu wrote:
On Wed, Feb 12, 2025 at 6:45 PM Josh Poimboeuf wrote:
On Wed, Feb 12, 2025 at 06:36:04PM -0800, Song Liu wrote:
[ 81.261748] copy_process+0xfdc/0xfd58 [livepatch_special_static]
Does t
Song Liu writes:
> On Thu, Feb 13, 2025 at 2:22 PM Puranjay Mohan wrote:
>>
>> Song Liu writes:
>>
>> > On Thu, Feb 13, 2025 at 12:38 AM Puranjay Mohan
>> > wrote:
>> > [...]
>> >>
>> >> P.S. - The livepatch doesn't have copy_process() but only copy_signal(),
>> >> yours had copy_process() so
On Thu, Feb 13, 2025 at 11:40:43AM -0800, Song Liu wrote:
> Yeah, objdump does show the same disassembly. However, if
> I open the file with gdb, and do "disassemble copy_process",
> the one in livepatch-special-static.o looks very weird.
The symbol table looks ok. I'm not sure why gdb is getting
Indu Bhagat writes:
> On 2/12/25 11:25 PM, Song Liu wrote:
>> On Wed, Feb 12, 2025 at 6:45 PM Josh Poimboeuf wrote:
>>>
>>> On Wed, Feb 12, 2025 at 06:36:04PM -0800, Song Liu wrote:
>> [ 81.261748] copy_process+0xfdc/0xfd58 [livepatch_special_static]
>
> Does that copy_process+0xf
On Thu, Feb 13, 2025 at 2:22 PM Puranjay Mohan wrote:
>
> Song Liu writes:
>
> > On Thu, Feb 13, 2025 at 12:38 AM Puranjay Mohan wrote:
> > [...]
> >>
> >> P.S. - The livepatch doesn't have copy_process() but only copy_signal(),
> >> yours had copy_process() somehow.
> >
> > In my build, copy_si
On Thu, Feb 13, 2025 at 3:23 PM Indu Bhagat wrote:
>
> On 2/12/25 11:25 PM, Song Liu wrote:
> > On Wed, Feb 12, 2025 at 6:45 PM Josh Poimboeuf wrote:
> >>
> >> On Wed, Feb 12, 2025 at 06:36:04PM -0800, Song Liu wrote:
> > [ 81.261748] copy_process+0xfdc/0xfd58 [livepatch_special_static]
>
On Thu, Feb 13, 2025 at 2:22 PM Puranjay Mohan wrote:
>
> Song Liu writes:
>
> > On Thu, Feb 13, 2025 at 12:38 AM Puranjay Mohan wrote:
> > [...]
> >>
> >> P.S. - The livepatch doesn't have copy_process() but only copy_signal(),
> >> yours had copy_process() somehow.
> >
> > In my build, copy_si
On 2/12/25 11:25 PM, Song Liu wrote:
On Wed, Feb 12, 2025 at 6:45 PM Josh Poimboeuf wrote:
On Wed, Feb 12, 2025 at 06:36:04PM -0800, Song Liu wrote:
[ 81.261748] copy_process+0xfdc/0xfd58 [livepatch_special_static]
Does that copy_process+0xfdc/0xfd58 resolve to this line in
copy_process(
Song Liu writes:
> On Thu, Feb 13, 2025 at 12:38 AM Puranjay Mohan wrote:
> [...]
>>
>> P.S. - The livepatch doesn't have copy_process() but only copy_signal(),
>> yours had copy_process() somehow.
>
> In my build, copy_signal is inlined to copy_process, unless I add noinline.
> If I do add noin
On Thu, Feb 13, 2025 at 12:38 AM Puranjay Mohan wrote:
[...]
>
> P.S. - The livepatch doesn't have copy_process() but only copy_signal(),
> yours had copy_process() somehow.
In my build, copy_signal is inlined to copy_process, unless I add noinline.
If I do add noinline, the issue will not reprod
On Wed, Feb 12, 2025 at 11:53 PM Puranjay Mohan wrote:
>
> Song Liu writes:
>
> > On Wed, Feb 12, 2025 at 11:26 PM Puranjay Mohan wrote:
> >>
> >> Song Liu writes:
> >>
> >> > On Wed, Feb 12, 2025 at 4:10 PM Indu Bhagat
> >> > wrote:
> >> >>
> >> >> On 2/12/25 3:32 PM, Song Liu wrote:
> >> >>
On Wed, Feb 12, 2025 at 11:46 PM Puranjay Mohan wrote:
>
> Song Liu writes:
>
> > On Wed, Feb 12, 2025 at 6:45 PM Josh Poimboeuf wrote:
> >>
> >> On Wed, Feb 12, 2025 at 06:36:04PM -0800, Song Liu wrote:
> >> > > > [ 81.261748] copy_process+0xfdc/0xfd58 [livepatch_special_static]
> >> > >
> >
Song Liu writes:
> On Wed, Feb 12, 2025 at 11:26 PM Puranjay Mohan wrote:
>>
>> Song Liu writes:
>>
>> > On Wed, Feb 12, 2025 at 4:10 PM Indu Bhagat wrote:
>> >>
>> >> On 2/12/25 3:32 PM, Song Liu wrote:
>> >> > I run some tests with this set and my RFC set [1]. Most of
>> >> > the test is don
Song Liu writes:
> On Wed, Feb 12, 2025 at 11:26 PM Puranjay Mohan wrote:
>>
>> Song Liu writes:
>>
>> > On Wed, Feb 12, 2025 at 4:10 PM Indu Bhagat wrote:
>> >>
>> >> On 2/12/25 3:32 PM, Song Liu wrote:
>> >> > I run some tests with this set and my RFC set [1]. Most of
>> >> > the test is don
Song Liu writes:
> On Wed, Feb 12, 2025 at 6:45 PM Josh Poimboeuf wrote:
>>
>> On Wed, Feb 12, 2025 at 06:36:04PM -0800, Song Liu wrote:
>> > > > [ 81.261748] copy_process+0xfdc/0xfd58 [livepatch_special_static]
>> > >
>> > > Does that copy_process+0xfdc/0xfd58 resolve to this line in
>> > >
On Wed, Feb 12, 2025 at 11:26 PM Puranjay Mohan wrote:
>
> Song Liu writes:
>
> > On Wed, Feb 12, 2025 at 4:10 PM Indu Bhagat wrote:
> >>
> >> On 2/12/25 3:32 PM, Song Liu wrote:
> >> > I run some tests with this set and my RFC set [1]. Most of
> >> > the test is done with kpatch-build. I tested
Song Liu writes:
> On Wed, Feb 12, 2025 at 4:10 PM Indu Bhagat wrote:
>>
>> On 2/12/25 3:32 PM, Song Liu wrote:
>> > I run some tests with this set and my RFC set [1]. Most of
>> > the test is done with kpatch-build. I tested both Puranjay's
>> > version [3] and my version [4].
>> >
>> > For gcc
On Wed, Feb 12, 2025 at 06:40:33PM -0800, Song Liu wrote:
> On Wed, Feb 12, 2025 at 4:10 PM Indu Bhagat wrote:
> >
> > On 2/12/25 3:32 PM, Song Liu wrote:
> > > I run some tests with this set and my RFC set [1]. Most of
> > > the test is done with kpatch-build. I tested both Puranjay's
> > > versi
On Wed, Feb 12, 2025 at 06:36:04PM -0800, Song Liu wrote:
> > > [ 81.261748] copy_process+0xfdc/0xfd58 [livepatch_special_static]
> >
> > Does that copy_process+0xfdc/0xfd58 resolve to this line in
> > copy_process()?
> >
> > refcount_inc(¤t->signal->sigcnt);
> >
> > Mayb
On Wed, Feb 12, 2025 at 4:10 PM Indu Bhagat wrote:
>
> On 2/12/25 3:32 PM, Song Liu wrote:
> > I run some tests with this set and my RFC set [1]. Most of
> > the test is done with kpatch-build. I tested both Puranjay's
> > version [3] and my version [4].
> >
> > For gcc 14.2.1, I have seen the fol
On Wed, Feb 12, 2025 at 3:49 PM Josh Poimboeuf wrote:
>
> On Wed, Feb 12, 2025 at 03:32:40PM -0800, Song Liu wrote:
> > [ 81.250437] [ cut here ]
> > [ 81.250818] refcount_t: saturated; leaking memory.
> > [ 81.251201] WARNING: CPU: 0 PID: 95 at lib/refcount.c:22
> >
On 2/12/25 3:32 PM, Song Liu wrote:
I run some tests with this set and my RFC set [1]. Most of
the test is done with kpatch-build. I tested both Puranjay's
version [3] and my version [4].
For gcc 14.2.1, I have seen the following issue with this
test [2]. This happens with both upstream and 6.13
On Wed, Feb 12, 2025 at 03:32:40PM -0800, Song Liu wrote:
> [ 81.250437] [ cut here ]
> [ 81.250818] refcount_t: saturated; leaking memory.
> [ 81.251201] WARNING: CPU: 0 PID: 95 at lib/refcount.c:22
> refcount_warn_saturate+0x6c/0x140
> [ 81.251841] Modules linked i
I run some tests with this set and my RFC set [1]. Most of
the test is done with kpatch-build. I tested both Puranjay's
version [3] and my version [4].
For gcc 14.2.1, I have seen the following issue with this
test [2]. This happens with both upstream and 6.13.2.
The livepatch loaded fine, but the
On Fri, Feb 7, 2025 at 4:16 AM Puranjay Mohan wrote:
>
> Yes, I think we should, but others people could add more to this.
>
> I have been testing this series with Kpatch and created a PR that works
> with this unwinder: https://github.com/dynup/kpatch/pull/1439
>
> For the modules, I think we n
On Fri, Feb 07, 2025 at 12:16:29PM +, Puranjay Mohan wrote:
> Weinan Liu writes:
> > Thank you for reporting this issue.
> > I just found out that Josh also intentionally uses '>' instead of '>=' for
> > the same reason
> > https://lore.kernel.org/lkml/2025015257.h64ftfnorofe7cb4@jpoimboe
Weinan Liu writes:
>> After some debugging this is what I found:
>>
>> devtmpfsd() calls devtmpfs_work_loop() which is marked '__noreturn' and has
>> an
>> infinite loop. The compiler puts the `bl` to devtmpfs_work_loop() as the the
>> last instruction in devtmpfsd() and therefore on entry to
> After some debugging this is what I found:
>
> devtmpfsd() calls devtmpfs_work_loop() which is marked '__noreturn' and has an
> infinite loop. The compiler puts the `bl` to devtmpfs_work_loop() as the the
> last instruction in devtmpfsd() and therefore on entry to
> devtmpfs_work_loop(),
> LR p
Puranjay Mohan writes:
> Weinan Liu writes:
>
>> This patchset implements a generic kernel sframe-based [1] unwinder.
>> The main goal is to support reliable stacktraces on arm64.
>>
>> On x86 orc unwinder provides reliable stacktraces. But arm64 misses the
>> required support from objtool: it c
Weinan Liu writes:
> This patchset implements a generic kernel sframe-based [1] unwinder.
> The main goal is to support reliable stacktraces on arm64.
>
> On x86 orc unwinder provides reliable stacktraces. But arm64 misses the
> required support from objtool: it cannot generate orc unwind tables
Hi Roman,
On Thu, Jan 30, 2025 at 11:01 AM Roman Gushchin
wrote:
>
> On Thu, Jan 30, 2025 at 10:34:09AM -0800, Song Liu wrote:
> > On Thu, Jan 30, 2025 at 9:59 AM Song Liu wrote:
> > >
> > > I missed this set before sending my RFC set. If this set works well, we
> > > won't need the other set. I
On Thu, Jan 30, 2025 at 10:34:09AM -0800, Song Liu wrote:
> On Thu, Jan 30, 2025 at 9:59 AM Song Liu wrote:
> >
> > I missed this set before sending my RFC set. If this set works well, we
> > won't need the other set. I will give this one a try.
>
> I just realized that llvm doesn't support sfram
On Thu, Jan 30, 2025 at 9:59 AM Song Liu wrote:
>
> I missed this set before sending my RFC set. If this set works well, we
> won't need the other set. I will give this one a try.
I just realized that llvm doesn't support sframe yet. So we (Meta) still
need some sframe-less approach before llvm s
I missed this set before sending my RFC set. If this set works well, we
won't need the other set. I will give this one a try.
Thanks,
Song
On Mon, Jan 27, 2025 at 1:33 PM Weinan Liu wrote:
>
> This patchset implements a generic kernel sframe-based [1] unwinder.
> The main goal is to support reli
Not only does objdump show that func_start_addr all 0s, but the
func_start_addr in the kernel module's sframe table is also incorrect. I'll
prepare a repro so we can investigate this.
>
> I can share a fix for 32589 so atleast we can verify that the starting
> point is sane.
>
Great! Thanks.
This
On 1/27/25 1:33 PM, Weinan Liu wrote:
This patchset implements a generic kernel sframe-based [1] unwinder.
The main goal is to support reliable stacktraces on arm64.
On x86 orc unwinder provides reliable stacktraces. But arm64 misses the
required support from objtool: it cannot generate orc unwi
This patchset implements a generic kernel sframe-based [1] unwinder.
The main goal is to support reliable stacktraces on arm64.
On x86 orc unwinder provides reliable stacktraces. But arm64 misses the
required support from objtool: it cannot generate orc unwind tables for
arm64.
Currently, there's
66 matches
Mail list logo
