include proper Kconfig.
This is largely based on [1] by Suraj Jitindar Singh.
[1] https://lore.kernel.org/all/20210604235930.603-1-sura...@amazon.com/
Cc: Suraj Jitindar Singh
Cc: Torsten Duwe
Acked-by: Miroslav Benes
Tested-by: Breno Leitao
Tested-by: Andrea della Porta
Signed-off-by: Song
Hi Will,
Thanks for your kind review!
On Thu, Jun 26, 2025 at 6:21 AM Will Deacon wrote:
>
> On Tue, Jun 17, 2025 at 10:37:34AM -0700, Song Liu wrote:
> > This is largely based on [1] by Suraj Jitindar Singh.
>
> I think it would be useful to preserve at least some parts
eitao
Tested-by: Andrea della Porta
Signed-off-by: Song Liu
---
Note: This patch depends on [3] and [4].
[3]
https://lore.kernel.org/linux-arm-kernel/2025052000.2237470-2-mark.rutl...@arm.com/
[4]
https://lore.kernel.org/linux-arm-kernel/20250603223417.3700218-1-dylanbha...@googl
On Tue, Jun 3, 2025 at 10:33 AM T.J. Mercier wrote:
>
> On Mon, May 12, 2025 at 2:12 AM Saket Kumar Bhaskar
> wrote:
> >
> > On linux-next, build for bpf selftest displays an error due to
> > mismatch in the expected function signature of bpf_testmod_test_read
> > and bpf_testmod_test_write.
> >
On Thu, May 22, 2025 at 11:43 AM Dylan Hatch wrote:
>
> Late module relocations are an issue on any arch that supports
> livepatch, so move the text_mutex locking to the livepatch core code.
>
> Signed-off-by: Dylan Hatch
Acked-by: Song Liu
e commits atop this one. If that looks good to you I
> suggest we post that as a series and ask Will and Catalin to take that
> as-is.
>
> I'll look at the actual patching bits now.
>
> Mark.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/
&g
On Thu, Apr 10, 2025 at 8:17 AM Petr Mladek wrote:
>
[...]
> >
> > [1]
> > https://lore.kernel.org/live-patching/20250127213310.2496133-1-wn...@google.com/
> > [2]
> > https://lore.kernel.org/live-patching/20250129232936.1795412-1-s...@kernel.org/
> > [3] https://sourceware.org/bugzilla/show_bug
D, 0 SKIPPED, 0 FAILED
>
> Fixes: a496d0cdc84d ("selftests/bpf: Add a test for kmem_cache_iter")
> Signed-off-by: T.J. Mercier
Acked-by: Song Liu
provide reliable livepatching.
Signed-off-by: Song Liu
---
arch/arm64/Kconfig | 2 +-
arch/arm64/kernel/stacktrace.c | 66 +-
2 files changed, 51 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 701d980ea921
Hi Petr,
> On Mar 25, 2025, at 8:53 AM, Petr Mladek wrote:
[...]
>>
>> Given the increasing need of livepatching, and relatively long time before
>> sframe is fully ready (for both gcc and clang), we would like to enable
>> livepatch without sframe.
>>
>> Thanks!
>>
>> [1]
>> https://lore.k
ld [2]. (This version includes commits that
are not merged to upstream kpatch yet).
[1] https://lore.kernel.org/all/20210604235930.603-1-sura...@amazon.com/
[2] https://github.com/liu-song-6/kpatch/tree/fb-6.13
Cc: Suraj Jitindar Singh
Cc: Torsten Duwe
Signed-off-by: Song Liu
Acked-by: Miroslav
On Thu, Mar 20, 2025 at 10:46 AM Weinan Liu wrote:
>
> On Thu, Mar 20, 2025 at 10:16 AM Song Liu wrote:
> >
> > static __always_inline void
> > @@ -230,8 +231,26 @@ kunwind_next_frame_record(struct kunwind_state *state)
> > new_fp = READ_ONCE(record->fp
anges v1 => v2:
1. Rework arch_stack_walk_reliable().
v1:
https://lore.kernel.org/live-patching/20250308012742.3208215-1-s...@kernel.org/
Song Liu (2):
arm64: Implement arch_stack_walk_reliable
arm64: Implement HAVE_LIVEPATCH
arch/arm64/Kconfig | 3 ++
arch/arm64/
On Wed, Mar 19, 2025 at 3:35 PM Josh Poimboeuf wrote:
>
> On Wed, Mar 19, 2025 at 02:37:06PM -0700, Song Liu wrote:
> > +noinline noinstr int arch_stack_walk_reliable(stack_trace_consume_fn
> > consume_entry,
> > + void *cookie,
provide reliable livepatching.
Signed-off-by: Song Liu
---
arch/arm64/Kconfig | 2 +-
arch/arm64/kernel/stacktrace.c | 70 ++
2 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 940343beb3d4
linux-arm-kernel/20241017092538.1859841-1-mark.rutl...@arm.com/
Changes v1 => v2:
1. Rework arch_stack_walk_reliable().
v1:
https://lore.kernel.org/live-patching/20250308012742.3208215-1-s...@kernel.org/
Song Liu (2):
arm64: Implement arch_stack_walk_reliable
arm64: Implement HAVE_LIVEPATC
ld [2]. (This version includes commits that
are not merged to upstream kpatch yet).
[1] https://lore.kernel.org/all/20210604235930.603-1-sura...@amazon.com/
[2] https://github.com/liu-song-6/kpatch/tree/fb-6.13
Cc: Suraj Jitindar Singh
Cc: Torsten Duwe
Signed-off-by: Song Liu
---
arch/arm64/Kc
On Wed, Mar 19, 2025 at 11:38 AM Weinan Liu wrote:
>
> On Tue, Mar 18, 2025 at 10:39 PM Josh Poimboeuf wrote:
> >
> > On Tue, Mar 18, 2025 at 08:58:52PM -0700, Song Liu wrote:
> > > On a closer look, I think we also need some logic in unwind_find_stack()
> &
On Tue, Mar 18, 2025 at 6:03 PM Josh Poimboeuf wrote:
>
> On Tue, Mar 18, 2025 at 04:38:20PM -0700, Song Liu wrote:
> > On Tue, Mar 18, 2025 at 4:00 PM Josh Poimboeuf wrote:
> > > - even in the -ENOENT case the unreliable bit has already been set
> > >
On Tue, Mar 18, 2025 at 4:00 PM Josh Poimboeuf wrote:
>
> On Tue, Mar 18, 2025 at 01:14:40PM -0700, Song Liu wrote:
> > >
> > > See for example all the error conditions in the x86 version of
> > > arch_stack_walk_reliable() and in arch/x86/kernel/unwind_frame.c.
&
Hi Josh,
Thanks for the review!
On Tue, Mar 18, 2025 at 11:45 AM Josh Poimboeuf wrote:
>
> On Fri, Mar 07, 2025 at 05:27:41PM -0800, Song Liu wrote:
> > With proper exception boundary detection, it is possible to implment
> > arch_stack_walk_reliable without sframe.
On Thu, Mar 13, 2025 at 11:12 AM Breno Leitao wrote:
>
> On Fri, Mar 07, 2025 at 05:27:41PM -0800, Song Liu wrote:
> > With proper exception boundary detection, it is possible to implment
> > arch_stack_walk_reliable without sframe.
> >
> > Note that, arch_stack_wa
On Fri, Mar 7, 2025 at 5:33 PM Blaise Boscaccy
wrote:
>
> This test exercises the kernel flag added to security_bpf by
> effectively blocking light-skeletons from loading while allowing
> normal skeletons to function as-is. Since this should work with any
> arbitrary BPF program, an existing progr
On Mon, Mar 10, 2025 at 11:11 AM Blaise Boscaccy
wrote:
[...]
> >
> > We are blindly blocking all security_bpf() with kernel=true here, so
> > any lskel load in parallel with this test may fail. On the other hand,
> > existing tests only block some operations under certain conditions.
> > For exam
On Mon, Mar 10, 2025 at 10:43 AM Blaise Boscaccy
wrote:
>
> Song Liu writes:
>
> > On Fri, Mar 7, 2025 at 5:33 PM Blaise Boscaccy
> > wrote:
> >>
> >> This test exercises the kernel flag added to security_bpf by
> >> effectively blocking light-s
to close_prog;
This goto is not necessary. But I don't think we need v8 just for this.
Acked-by: Song Liu
> +
> +close_prog:
> + if (skel)
> + kfunc_call_test__destroy(skel);
> + if (lskel)
> + kfunc_call_test_lskel__destroy(lskel);
[...]
ld [2]. (This version includes commits that
are not merged to upstream kpatch yet).
[1] https://lore.kernel.org/all/20210604235930.603-1-sura...@amazon.com/
[2] https://github.com/liu-song-6/kpatch/tree/fb-6.13
Cc: Suraj Jitindar Singh
Cc: Torsten Duwe
Signed-off-by: Song Liu
---
arch/arm64/Kc
provide reliable livepatching.
This version has been inspired by Weinan Liu's patch [1].
[1]
https://lore.kernel.org/live-patching/20250127213310.2496133-7-wn...@google.com/
Signed-off-by: Song Liu
---
arch/arm64/Kconfig | 2 +-
arch/arm64/include/asm/stacktrace/com
linux-arm-kernel/20241017092538.1859841-1-mark.rutl...@arm.com/
Song Liu (2):
arm64: Implement arch_stack_walk_reliable
arm64: Implement HAVE_LIVEPATCH
arch/arm64/Kconfig | 3 ++
arch/arm64/include/asm/stacktrace/common.h | 1 +
arch/arm64/include/asm/thread_i
On Fri, Mar 7, 2025 at 1:37 PM Blaise Boscaccy
wrote:
>
> This test exercises the kernel flag added to security_bpf by
> effectively blocking light-skeletons from loading while allowing
> normal skeletons to function as-is. Since this should work with any
> arbitrary BPF program, an existing progr
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
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
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 Li
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
> &
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 Li
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 inst
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 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(),
> >>
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] cop
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(),
> >>
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
> >&
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]
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
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].
> >
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:
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 Wed, Feb 5, 2025 at 6:55 PM Yafang Shao wrote:
[...]
> > I think we should first understand why the trampoline is not
> > freed.
>
> IIUC, the fexit works as follows,
>
> bpf_trampoline
> + __bpf_tramp_enter
>+ percpu_ref_get(&tr->pcref);
>
> + call do_exit()
>
> + __bpf_t
On Wed, Feb 5, 2025 at 6:43 AM Yafang Shao wrote:
>
> On Tue, Feb 4, 2025 at 5:53 AM Song Liu wrote:
> >
> > On Mon, Feb 3, 2025 at 1:45 AM Yafang Shao wrote:
> > [...]
> > >
> > > If you’re managing a large fleet of servers, this issue is far from
>
On Mon, Feb 3, 2025 at 1:45 AM Yafang Shao wrote:
[...]
>
> If you’re managing a large fleet of servers, this issue is far from
> negligible.
>
> >
> > > Can you provide examples of companies that use atomic replacement at
> > > scale in their production environments?
> >
> > At least SUSE uses i
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
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 a
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
ld [2]. (This version includes commits that
are not merged to upstream kpatch yet).
[1] https://lore.kernel.org/all/20210604235930.603-1-sura...@amazon.com/
[2] https://github.com/liu-song-6/kpatch/tree/fb-6.13
Cc: Suraj Jitindar Singh
Cc: Torsten Duwe
Signed-off-by: Song Liu
---
arch/arm64/Kc
Let do_kunwind() and kunwind_stack_walk() return the state of stack walk
properly to the caller, and use them in arch_stack_walk_reliable(). This
can be used to enable livepatching for arm64.
Signed-off-by: Song Liu
---
arch/arm64/Kconfig | 2 +-
arch/arm64/kernel/stacktrace.c | 35
Hi Josh,
On Wed, Sep 11, 2024 at 9:20 AM Josh Poimboeuf wrote:
[...]
> > Do not get me wrong. I do not expect that the upstream variant would
> > be feature complete from the beginning. I just want to get a picture
> > how far it is. The code will be maintained only when it would have
> > users.
On Mon, Sep 9, 2024 at 2:19 PM Josh Poimboeuf wrote:
>
> On Sat, Sep 07, 2024 at 10:04:25PM -0700, Song Liu wrote:
> > I think gcc doesn't complain, but clang does:
> >
> > $ cat ttt.c
> > static inline void ret(void)
> > {
> > return;
&g
On Sat, Sep 7, 2024 at 1:14 PM Josh Poimboeuf wrote:
>
> On Sat, Sep 07, 2024 at 10:43:10AM -0700, Song Liu wrote:
> > clang gives the following:
> >
> > elf.c:102:1: error: unused function '__sym_remove'
> > [-Werror,-Wunused-function]
> >
On Fri, Sep 6, 2024 at 11:46 PM Josh Poimboeuf wrote:
>
> On Tue, Sep 03, 2024 at 10:32:00AM -0700, Song Liu wrote:
> > +++ w/tools/objtool/elf.c
> > @@ -468,10 +468,8 @@ static void elf_add_symbol(struct elf *elf,
> > struct symbol *sym)
> > *
> >
On Thu, Sep 5, 2024 at 12:13 AM Josh Poimboeuf wrote:
>
> On Wed, Sep 04, 2024 at 09:14:00PM -0700, Josh Poimboeuf wrote:
>
> > + if (!!nr_objs) {
> ^^
> oops
>
> Fixed version:
The fixed version works for the following cases with gcc-12:
1. no BTF, no IBT;
2. with BT
On Wed, Sep 4, 2024 at 1:59 PM Josh Poimboeuf wrote:
>
> On Wed, Sep 04, 2024 at 01:23:55PM -0700, Song Liu wrote:
> > Hi Josh,
> >
> > Thanks for the fix! The gcc kernel now compiles.
> >
> > I am now testing with the attached config file (where I disabled
Hi Josh,
Thanks for the patchset! We really need this work so that we can undo our
hack for LTO enabled kernels.
On Mon, Sep 2, 2024 at 9:00 PM Josh Poimboeuf wrote:
>
> Hi,
>
> Here's a new way to build livepatch modules called klp-build.
>
> I started working on it when I realized that objtool
Hi Kees,
> On Aug 15, 2024, at 9:05 AM, Kees Cook wrote:
>
> On Mon, Aug 12, 2024 at 06:13:22PM +0000, Song Liu wrote:
>> Hi Luis,
>>
>>> On Aug 12, 2024, at 9:57 AM, Luis Chamberlain wrote:
>>>
>>> On Mon, Aug 12, 2024 at 09:21:02AM -0700,
PM, Masami Hiramatsu wrote:
>
> On Wed, 7 Aug 2024 15:05:11 -0700
> Song Liu wrote:
>
>> With CONFIG_LTO_CLANG, the compiler/linker adds .llvm. suffix to
>> local symbols to avoid duplications. Existing scripts/kallsyms sorts
>> symbols without .llvm. suffix. However,
> On Aug 7, 2024, at 3:05 PM, Song Liu wrote:
>
> With CONFIG_LTO_CLANG=y, the compiler may add .llvm. suffix to
> function names to avoid duplication. APIs like kallsyms_lookup_name()
> and kallsyms_on_each_match_symbol() tries to match these symbol names
> without the
> On Aug 7, 2024, at 3:05 PM, Song Liu wrote:
>
> Cleaning up the symbols causes various issues afterwards. Let's sort
> the list based on original name.
>
> Signed-off-by: Song Liu
Fixes: 8cc32a9bbf29 ("kallsyms: strip LTO-only suffixes from promoted global
functions")
Hi Luis,
> On Aug 12, 2024, at 9:57 AM, Luis Chamberlain wrote:
>
> On Mon, Aug 12, 2024 at 09:21:02AM -0700, Song Liu wrote:
>> Hi folks,
>>
>> Do we have more concerns and/or suggestions with this set? If not,
>> what would be the next step for it?
>
&
Hi folks,
Do we have more concerns and/or suggestions with this set? If not,
what would be the next step for it?
Thanks,
Song
On Wed, Aug 7, 2024 at 3:05 PM Song Liu wrote:
>
> With CONFIG_LTO_CLANG, the compiler/linker adds .llvm. suffix to
> local symbols to avoid duplications.
Hi Alessandro,
> On Aug 8, 2024, at 11:20 PM, Alessandro Carminati
> wrote:
>
> Hello,
> sorry to join late at the party.
>
> Il giorno gio 8 ago 2024 alle ore 11:59 Petr Mladek
> ha scritto:
>>
>> On Wed 2024-08-07 20:48:48, Song Liu wrote:
>>>
> On Aug 9, 2024, at 8:40 AM, Petr Mladek wrote:
>
> On Thu 2024-08-08 15:20:26, Song Liu wrote:
>>
>>
>>> On Aug 8, 2024, at 2:59 AM, Petr Mladek wrote:
>>>
>>> On Wed 2024-08-07 20:48:48, Song Liu wrote:
>>>>
>>>>
> On Aug 8, 2024, at 2:59 AM, Petr Mladek wrote:
>
> On Wed 2024-08-07 20:48:48, Song Liu wrote:
>>
>>
>>> On Aug 7, 2024, at 8:33 AM, Sami Tolvanen wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Aug 7, 2024 at 3:08 AM Masami Hirama
> On Aug 8, 2024, at 2:48 AM, Petr Mladek wrote:
>
> On Wed 2024-08-07 19:46:31, Song Liu wrote:
>>
>>
>>> On Aug 7, 2024, at 7:58 AM, zhang warden wrote:
>>>
>>>
>>>> In my GCC built, we have suffixes like ".constprop.0&q
> On Aug 8, 2024, at 3:20 AM, Petr Mladek wrote:
>
> On Fri 2024-08-02 14:08:34, Song Liu wrote:
>> With CONFIG_LTO_CLANG=y, the compiler may add suffix to function names
>> to avoid duplication. This causes confusion with users of kallsyms.
>> On one hand, users lik
5431275852. This turned out to be problematic
for use cases that require exact match, for example, livepatch.
Fix this by making the APIs to match symbols exactly.
Also cleanup kallsyms_selftests accordingly.
Signed-off-by: Song Liu
---
kernel/kallsyms.c
Cleaning up the symbols causes various issues afterwards. Let's sort
the list based on original name.
Signed-off-by: Song Liu
---
scripts/kallsyms.c | 31 ++-
scripts/link-vmlinux.sh | 4
2 files changed, 2 insertions(+), 33 deletions(-)
diff --
tching/20240730005433.3559731-1-s...@kernel.org/T/#u
Song Liu (2):
kallsyms: Do not cleanup .llvm. suffix before sorting symbols
kallsyms: Match symbols exactly with CONFIG_LTO_CLANG
kernel/kallsyms.c | 55 +-
kernel/kallsyms_selftest.
> On Aug 7, 2024, at 1:55 PM, Masami Hiramatsu wrote:
>
> On Wed, 7 Aug 2024 00:19:20 +0000
> Song Liu wrote:
>
>>
>>
>>> On Aug 6, 2024, at 5:01 PM, Masami Hiramatsu wrote:
>>>
>>> On Tue, 6 Aug 2024 20:12:55 +
>>> Son
> On Aug 7, 2024, at 8:33 AM, Sami Tolvanen wrote:
>
> Hi,
>
> On Wed, Aug 7, 2024 at 3:08 AM Masami Hiramatsu wrote:
>>
>> On Wed, 7 Aug 2024 00:19:20 +
>> Song Liu wrote:
>>
>>> Do you mean we do not want patch 3/3, but would
> On Aug 7, 2024, at 1:40 PM, Song Liu wrote:
>
>
>
>> On Aug 7, 2024, at 1:08 PM, Steven Rostedt wrote:
>>
>> On Wed, 7 Aug 2024 19:41:11 +
>> Song Liu wrote:
>>
>>
>>> It appears there are multiple APIs that may need
> On Aug 7, 2024, at 1:08 PM, Steven Rostedt wrote:
>
> On Wed, 7 Aug 2024 19:41:11 +0000
> Song Liu wrote:
>
>
>> It appears there are multiple APIs that may need change. For example, on gcc
>> built kernel, /sys/kernel/tracing/available_filter_function
> On Aug 7, 2024, at 7:58 AM, zhang warden wrote:
>
>
>> In my GCC built, we have suffixes like ".constprop.0", ".part.0", ".isra.0",
>> and ".isra.0.cold".
>
> A fresher's eye, I met sometime when try to build a livepatch module and
> found some mistake caused by ".constprop.0" ".part.0" w
> On Aug 7, 2024, at 3:08 AM, Masami Hiramatsu wrote:
>
> On Wed, 7 Aug 2024 00:19:20 +0000
> Song Liu wrote:
>
>>
>>
>>> On Aug 6, 2024, at 5:01 PM, Masami Hiramatsu wrote:
>>>
>>> On Tue, 6 Aug 2024 20:12:55 +
>>> Son
> On Aug 6, 2024, at 5:01 PM, Masami Hiramatsu wrote:
>
> On Tue, 6 Aug 2024 20:12:55 +0000
> Song Liu wrote:
>
>>
>>
>>> On Aug 6, 2024, at 1:01 PM, Steven Rostedt wrote:
>>>
>>> On Tue, 6 Aug 2024 16:00:49 -0400
>>> Steven
> On Aug 6, 2024, at 1:01 PM, Steven Rostedt wrote:
>
> On Tue, 6 Aug 2024 16:00:49 -0400
> Steven Rostedt wrote:
>
> + if (IS_ENABLED(CONFIG_LTO_CLANG) && !addr)
> + addr = kallsyms_lookup_name_without_suffix(trace_kprobe_symbol(tk));
> +
So you do the lookup twice
Hi Steven,
> On Aug 6, 2024, at 11:44 AM, Steven Rostedt wrote:
>
> On Fri, 2 Aug 2024 14:08:35 -0700
> Song Liu wrote:
>
>> Use the new kallsyms APIs that matches symbols name with .XXX
>> suffix. This allows userspace tools to get kprobes on the expected
>>
Hi Masami,
On Mon, Aug 5, 2024 at 6:45 AM Masami Hiramatsu wrote:
>
> On Fri, 2 Aug 2024 14:08:34 -0700
> Song Liu wrote:
>
> > With CONFIG_LTO_CLANG=y, the compiler may add suffix to function names
> > to avoid duplication. This causes confusion with users of kallsyms
Use the new kallsyms APIs that matches symbols name with .XXX
suffix. This allows userspace tools to get kprobes on the expected
function name, while the actual symbol has a .llvm. suffix.
This only effects kernel compile with CONFIG_LTO_CLANG.
Signed-off-by: Song Liu
---
kernel/kprobes.c
. kallsyms_on_each_match_symbol_without_suffix()
These APIs will be used by kprobe.
Also cleanup some code and update kallsyms_selftests accordingly.
Signed-off-by: Song Liu
---
include/linux/kallsyms.h | 14 ++
kernel/kallsyms.c | 88 ++
kernel/kallsyms_selftest.c | 75
Cleaning up the symbols causes various issues afterwards. Let's sort
the list based on original name and handle suffix later during the
symbol lookup.
Signed-off-by: Song Liu
---
scripts/kallsyms.c | 31 ++-
scripts/link-vmlinux.sh | 4
2 files chang
v1:
https://lore.kernel.org/live-patching/20240730005433.3559731-1-s...@kernel.org/T/#u
Song Liu (3):
kallsyms: Do not cleanup .llvm. suffix before sorting symbols
kallsyms: Add APIs to match symbol without . suffix.
tracing/kprobes: Use APIs that matches symbols without .XXX suf
> On Jul 29, 2024, at 5:54 PM, Song Liu wrote:
>
> With CONFIG_LTO_CLANG=y, the compiler may add suffix to function names
> to avoid duplication. This causes confusion with users of kallsyms.
> On one hand, users like livepatch are required to match the symbols
> exactly.
Hi Petr,
> On Aug 2, 2024, at 8:45 AM, Petr Mladek wrote:
[...]
>
> IMHO, it depends on the use case. Let's keep "ping_table/"
> as an example. Why people would want to trace this function?
> There might be various reasons, for example:
>
> 1. ping_table.llvm.15394922576589127018 appeared i
> On Aug 1, 2024, at 6:18 PM, Leizhen (ThunderTown)
> wrote:
>
> On 2024/7/31 9:00, Song Liu wrote:
>> Hi Masami,
>>
>>> On Jul 30, 2024, at 6:03 AM, Masami Hiramatsu wrote:
>>>
>>> On Mon, 29 Jul 2024 17:54:32 -0700
>>> Song Liu
Hi Masami,
> On Jul 30, 2024, at 6:04 AM, Masami Hiramatsu wrote:
>
> On Mon, 29 Jul 2024 17:54:33 -0700
> Song Liu wrote:
>
>> Use the new kallsyms APIs that matches symbols name with .llvm.
>> suffix. This allows userspace tools to get kprobes on the expected
Hi Masami,
> On Jul 30, 2024, at 6:03 AM, Masami Hiramatsu wrote:
>
> On Mon, 29 Jul 2024 17:54:32 -0700
> Song Liu wrote:
>
>> With CONFIG_LTO_CLANG=y, the compiler may add suffix to function names
>> to avoid duplication. This causes confusion with users of kall
On Mon, Jul 29, 2024 at 5:54 PM Song Liu wrote:
>
> With CONFIG_LTO_CLANG, the compiler/linker adds .llvm. suffix to
> local symbols to avoid duplications. Existing scripts/kallsyms sorts
> symbols without .llvm. suffix. However, this causes quite some
> issues later on. Some us
Use the new kallsyms APIs that matches symbols name with .llvm.
suffix. This allows userspace tools to get kprobes on the expected
function name, while the actual symbol has a .llvm. suffix.
This only effects kernel compared with CONFIG_LTO_CLANG.
Signed-off-by: Song Liu
---
kernel/trace
. kallsyms_on_each_match_symbol_or_prefix()
These APIs will be used by kprobe.
Also cleanup some code and adjust kallsyms_selftests accordingly.
Signed-off-by: Song Liu
---
include/linux/kallsyms.h | 14 +++
kernel/kallsyms.c | 83 ++
kernel/kallsyms_selftest.c | 22
Cleaning up the symbols causes various issues afterwards. Let's sort
the list based on original name and handle suffix later during the
symbol lookup.
Signed-off-by: Song Liu
---
scripts/kallsyms.c | 31 ++-
scripts/link-vmlinux.sh | 4
2 files chang
symbols with suffix. Use the new APIs in tracing/kprobes.
Song Liu (3):
kallsyms: Do not cleanup .llvm. suffix before sorting symbols
kallsyms: Add APIs to match symbol without .llmv. suffix.
tracing/kprobes: Use APIs that matches symbols with .llvm.
suffix
include/linux/kallsyms.h| 14
1 - 100 of 1056 matches
Mail list logo
