* Re: [RFC bpf-next 00/12] bpf: tracing_multi link
From: Alexei Starovoitov @ 2026-02-03 23:17 UTC (permalink / raw)
To: Jiri Olsa
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, bpf,
linux-trace-kernel, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Menglong Dong, Steven Rostedt
In-Reply-To: <20260203093819.2105105-1-jolsa@kernel.org>
On Tue, Feb 3, 2026 at 1:38 AM Jiri Olsa <jolsa@kernel.org> wrote:
>
> hi,
> as an option to Meglong's change [1] I'm sending proposal for tracing_multi
> link that does not add static trampoline but attaches program to all needed
> trampolines.
>
> This approach keeps the same performance but has some drawbacks:
>
> - when attaching 20k functions we allocate and attach 20k trampolines
> - during attachment we hold each trampoline mutex, so for above
> 20k functions we will hold 20k mutexes during the attachment,
> should be very prone to deadlock, but haven't hit it yet
If you check that it's sorted and always take them in the same order
then there will be no deadlock.
Or just grab one global mutex first and then grab trampolines mutexes
next in any order. The global one will serialize this attach operation.
> It looks the trampoline allocations/generation might not be big a problem
> and I'll try to find a solution for holding that many mutexes. If there's
> no better solution I think having one read/write mutex for tracing multi
> link attach/detach should work.
If you mean to have one global mutex as I proposed above then I don't see
a downside. It only serializes multiple libbpf calls.
overall makes sense to me.
^ permalink raw reply
* Re: [PATCH] bpf: add missing __printf attributes
From: Arnd Bergmann @ 2026-02-03 23:21 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Arnd Bergmann, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Song Liu, KP Singh, Matt Bobrowski,
Steven Rostedt, Masami Hiramatsu, Martin KaFai Lau,
Eduard Zingerman, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Jiri Olsa, Mathieu Desnoyers,
Mykyta Yatsenko, Kumar Kartikeya Dwivedi, bpf, LKML,
linux-trace-kernel
In-Reply-To: <CAADnVQK3eZp3yp35OUx8j1UBsQFhgsn5-4VReqAJ=68PaaKYmg@mail.gmail.com>
On Tue, Feb 3, 2026, at 19:11, Alexei Starovoitov wrote:
> On Tue, Feb 3, 2026 at 9:44 AM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tue, Feb 3, 2026, at 18:24, Alexei Starovoitov wrote:
>> I also see the comment about bstr_printf() mention that it
>> uses a vsnprintf() compatible format, which would indicate that
>> marking the format argument isn't wrong, though I agree it is
>> not actually useful if there are no callers that pass a string
>> literal.
>
> In general I don't think it's a good idea to add nop annotations
> just to shut up over eager compiler warning.
I've tried removing these three below, which now gives me
a clean build with -Wsuggest-attribute=format, after the
other three patches I posted for unrelated code.
Arnd
diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index d6ebf0596510..2fb266ea69fa 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -181,7 +181,6 @@ int seq_open_private(struct file *, const struct seq_operations *, int);
int seq_release_private(struct inode *, struct file *);
#ifdef CONFIG_BINARY_PRINTF
-__printf(2, 0)
void seq_bprintf(struct seq_file *m, const char *f, const u32 *binary);
#endif
diff --git a/include/linux/string.h b/include/linux/string.h
index 1b564c36d721..b850bd91b3d8 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -336,8 +336,8 @@ int __sysfs_match_string(const char * const *array, size_t n, const char *s);
#define sysfs_match_string(_a, _s) __sysfs_match_string(_a, ARRAY_SIZE(_a), _s)
#ifdef CONFIG_BINARY_PRINTF
-__printf(3, 0) int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args);
-__printf(3, 0) int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf);
+int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args);
+int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf);
#endif
extern ssize_t memory_read_from_buffer(void *to, size_t count, loff_t *ppos,
^ permalink raw reply related
* Re: [PATCH] bpf: add missing __printf attributes
From: Alexei Starovoitov @ 2026-02-04 0:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Song Liu, KP Singh, Matt Bobrowski,
Steven Rostedt, Masami Hiramatsu, Martin KaFai Lau,
Eduard Zingerman, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Jiri Olsa, Mathieu Desnoyers,
Mykyta Yatsenko, Kumar Kartikeya Dwivedi, bpf, LKML,
linux-trace-kernel
In-Reply-To: <0d5b64a5-8cf9-45c7-8848-ac62d3fdca44@app.fastmail.com>
On Tue, Feb 3, 2026 at 3:21 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Feb 3, 2026, at 19:11, Alexei Starovoitov wrote:
> > On Tue, Feb 3, 2026 at 9:44 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Tue, Feb 3, 2026, at 18:24, Alexei Starovoitov wrote:
> >> I also see the comment about bstr_printf() mention that it
> >> uses a vsnprintf() compatible format, which would indicate that
> >> marking the format argument isn't wrong, though I agree it is
> >> not actually useful if there are no callers that pass a string
> >> literal.
> >
> > In general I don't think it's a good idea to add nop annotations
> > just to shut up over eager compiler warning.
>
> I've tried removing these three below, which now gives me
> a clean build with -Wsuggest-attribute=format, after the
> other three patches I posted for unrelated code.
Nice. lgtm. Ack.
> Arnd
>
> diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
> index d6ebf0596510..2fb266ea69fa 100644
> --- a/include/linux/seq_file.h
> +++ b/include/linux/seq_file.h
> @@ -181,7 +181,6 @@ int seq_open_private(struct file *, const struct seq_operations *, int);
> int seq_release_private(struct inode *, struct file *);
>
> #ifdef CONFIG_BINARY_PRINTF
> -__printf(2, 0)
> void seq_bprintf(struct seq_file *m, const char *f, const u32 *binary);
> #endif
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 1b564c36d721..b850bd91b3d8 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -336,8 +336,8 @@ int __sysfs_match_string(const char * const *array, size_t n, const char *s);
> #define sysfs_match_string(_a, _s) __sysfs_match_string(_a, ARRAY_SIZE(_a), _s)
>
> #ifdef CONFIG_BINARY_PRINTF
> -__printf(3, 0) int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args);
> -__printf(3, 0) int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf);
> +int vbin_printf(u32 *bin_buf, size_t size, const char *fmt, va_list args);
> +int bstr_printf(char *buf, size_t size, const char *fmt, const u32 *bin_buf);
> #endif
>
> extern ssize_t memory_read_from_buffer(void *to, size_t count, loff_t *ppos,
^ permalink raw reply
* Re: [PATCH v7 3/6] x86/asm: Simplify VDSO DWARF generation
From: H. Peter Anvin @ 2026-02-04 0:44 UTC (permalink / raw)
To: Jens Remus, linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
Liam R. Howlett, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Heiko Carstens,
Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-4-jremus@linux.ibm.com>
On 2026-02-03 09:19, Jens Remus wrote:
> From: Josh Poimboeuf <jpoimboe@kernel.org>
>
> Add CFI_STARTPROC and CFI_ENDPROC annotations to the SYM_FUNC_* macros
> so the VDSO asm functions don't need to add them manually. Note this
> only affects VDSO, the CFI_* macros are empty for the kernel proper.
>
> [ Jens Remus: Reword commit subject and message as suggested by Josh. ]
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> ---
> arch/x86/entry/vdso/common/vdso-layout.lds.S | 2 +-
> .../x86/entry/vdso/vdso64/vgetrandom-chacha.S | 2 --
> arch/x86/entry/vdso/vdso64/vsgx.S | 4 ---
> arch/x86/include/asm/linkage.h | 33 +++++++++++++++----
> arch/x86/include/asm/vdso.h | 1 -
> 5 files changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/arch/x86/entry/vdso/common/vdso-layout.lds.S b/arch/x86/entry/vdso/common/vdso-layout.lds.S
> index a1e30be3e83d..856b8b9d278c 100644
> --- a/arch/x86/entry/vdso/common/vdso-layout.lds.S
> +++ b/arch/x86/entry/vdso/common/vdso-layout.lds.S
> @@ -1,5 +1,5 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> -#include <asm/vdso.h>
> +#include <asm/page_types.h>
> #include <asm/vdso/vsyscall.h>
> #include <vdso/datapage.h>
>
> diff --git a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
> index cc82da9216fb..a33212594731 100644
> --- a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
> +++ b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
> @@ -22,7 +22,6 @@ CONSTANTS: .octa 0x6b20657479622d323320646e61707865
> * rcx: number of 64-byte blocks to write to output
> */
> SYM_FUNC_START(__arch_chacha20_blocks_nostack)
> - CFI_STARTPROC
> .set output, %rdi
> .set key, %rsi
> .set counter, %rdx
> @@ -175,5 +174,4 @@ SYM_FUNC_START(__arch_chacha20_blocks_nostack)
> pxor temp,temp
>
> ret
> - CFI_ENDPROC
> SYM_FUNC_END(__arch_chacha20_blocks_nostack)
> diff --git a/arch/x86/entry/vdso/vdso64/vsgx.S b/arch/x86/entry/vdso/vdso64/vsgx.S
> index 37a3d4c02366..c0342238c976 100644
> --- a/arch/x86/entry/vdso/vdso64/vsgx.S
> +++ b/arch/x86/entry/vdso/vdso64/vsgx.S
> @@ -24,8 +24,6 @@
> .section .text, "ax"
>
> SYM_FUNC_START(__vdso_sgx_enter_enclave)
> - /* Prolog */
> - .cfi_startproc
> push %rbp
> .cfi_adjust_cfa_offset 8
> .cfi_rel_offset %rbp, 0
> @@ -143,8 +141,6 @@ SYM_FUNC_START(__vdso_sgx_enter_enclave)
> jle .Lout
> jmp .Lenter_enclave
>
> - .cfi_endproc
> -
> _ASM_VDSO_EXTABLE_HANDLE(.Lenclu_eenter_eresume, .Lhandle_exception)
>
> SYM_FUNC_END(__vdso_sgx_enter_enclave)
> diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
> index 9d38ae744a2e..9d7f90c57451 100644
> --- a/arch/x86/include/asm/linkage.h
> +++ b/arch/x86/include/asm/linkage.h
> @@ -40,6 +40,10 @@
>
> #ifdef __ASSEMBLER__
>
> +#ifndef LINKER_SCRIPT
> +#include <asm/dwarf2.h>
> +#endif
> +
> #if defined(CONFIG_MITIGATION_RETHUNK) && !defined(__DISABLE_EXPORTS) && !defined(BUILD_VDSO)
> #define RET jmp __x86_return_thunk
> #else /* CONFIG_MITIGATION_RETPOLINE */
> @@ -112,34 +116,51 @@
> # define SYM_FUNC_ALIAS_MEMFUNC SYM_FUNC_ALIAS
> #endif
>
> +#define __SYM_FUNC_START \
> + CFI_STARTPROC ASM_NL
> +
> +#define __SYM_FUNC_END \
> + CFI_ENDPROC ASM_NL
> +
> /* SYM_TYPED_FUNC_START -- use for indirectly called globals, w/ CFI type */
> #define SYM_TYPED_FUNC_START(name) \
> SYM_TYPED_START(name, SYM_L_GLOBAL, SYM_F_ALIGN) \
> + __SYM_FUNC_START \
> ENDBR
>
> /* SYM_FUNC_START -- use for global functions */
> #define SYM_FUNC_START(name) \
> - SYM_START(name, SYM_L_GLOBAL, SYM_F_ALIGN)
> + SYM_START(name, SYM_L_GLOBAL, SYM_F_ALIGN) \
> + __SYM_FUNC_START
>
> /* SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment */
> #define SYM_FUNC_START_NOALIGN(name) \
> - SYM_START(name, SYM_L_GLOBAL, SYM_A_NONE)
> + SYM_START(name, SYM_L_GLOBAL, SYM_A_NONE) \
> + __SYM_FUNC_START
>
> /* SYM_FUNC_START_LOCAL -- use for local functions */
> #define SYM_FUNC_START_LOCAL(name) \
> - SYM_START(name, SYM_L_LOCAL, SYM_F_ALIGN)
> + SYM_START(name, SYM_L_LOCAL, SYM_F_ALIGN) \
> + __SYM_FUNC_START
>
> /* SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o alignment */
> #define SYM_FUNC_START_LOCAL_NOALIGN(name) \
> - SYM_START(name, SYM_L_LOCAL, SYM_A_NONE)
> + SYM_START(name, SYM_L_LOCAL, SYM_A_NONE) \
> + __SYM_FUNC_START
>
> /* SYM_FUNC_START_WEAK -- use for weak functions */
> #define SYM_FUNC_START_WEAK(name) \
> - SYM_START(name, SYM_L_WEAK, SYM_F_ALIGN)
> + SYM_START(name, SYM_L_WEAK, SYM_F_ALIGN) \
> + __SYM_FUNC_START
>
> /* SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment */
> #define SYM_FUNC_START_WEAK_NOALIGN(name) \
> - SYM_START(name, SYM_L_WEAK, SYM_A_NONE)
> + SYM_START(name, SYM_L_WEAK, SYM_A_NONE) \
> + __SYM_FUNC_START
> +
> +#define SYM_FUNC_END(name) \
> + __SYM_FUNC_END \
> + SYM_END(name, SYM_T_FUNC)
>
> /*
> * Expose 'sym' to the startup code in arch/x86/boot/startup/, by emitting an
> diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
> index e8afbe9faa5b..498ac423741c 100644
> --- a/arch/x86/include/asm/vdso.h
> +++ b/arch/x86/include/asm/vdso.h
> @@ -2,7 +2,6 @@
> #ifndef _ASM_X86_VDSO_H
> #define _ASM_X86_VDSO_H
>
> -#include <asm/page_types.h>
> #include <linux/linkage.h>
> #include <linux/init.h>
>
Makes sense to me.
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
^ permalink raw reply
* Re: [PATCH v7 1/6] x86/vdso: Fix DWARF generation for getrandom()
From: H. Peter Anvin @ 2026-02-04 0:43 UTC (permalink / raw)
To: Jens Remus, linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
Liam R. Howlett, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Heiko Carstens,
Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-2-jremus@linux.ibm.com>
On 2026-02-03 09:19, Jens Remus wrote:
> From: Josh Poimboeuf <jpoimboe@kernel.org>
>
> Add CFI annotations to the VDSO implementation of getrandom() so it will
> have valid DWARF unwinding metadata.
>
> Fixes: 33385150ac45 ("x86: vdso: Wire up getrandom() vDSO implementation")
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> ---
> arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
> index bcba5639b8ee..cc82da9216fb 100644
> --- a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
> +++ b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
> @@ -4,7 +4,7 @@
> */
>
> #include <linux/linkage.h>
> -#include <asm/frame.h>
> +#include <asm/dwarf2.h>
>
> .section .rodata, "a"
> .align 16
> @@ -22,7 +22,7 @@ CONSTANTS: .octa 0x6b20657479622d323320646e61707865
> * rcx: number of 64-byte blocks to write to output
> */
> SYM_FUNC_START(__arch_chacha20_blocks_nostack)
> -
> + CFI_STARTPROC
> .set output, %rdi
> .set key, %rsi
> .set counter, %rdx
> @@ -175,4 +175,5 @@ SYM_FUNC_START(__arch_chacha20_blocks_nostack)
> pxor temp,temp
>
> ret
> + CFI_ENDPROC
> SYM_FUNC_END(__arch_chacha20_blocks_nostack)
Looks good to me.
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
^ permalink raw reply
* Re: [PATCH v7 2/6] x86/asm: Avoid emitting DWARF CFI for non-VDSO
From: H. Peter Anvin @ 2026-02-04 0:43 UTC (permalink / raw)
To: Jens Remus, linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
Liam R. Howlett, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Heiko Carstens,
Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-3-jremus@linux.ibm.com>
On 2026-02-03 09:19, Jens Remus wrote:
> From: Josh Poimboeuf <jpoimboe@kernel.org>
>
> It was decided years ago that .cfi_* annotations aren't maintainable in
> the kernel. They were replaced by objtool unwind hints. For the kernel
> proper, ensure the CFI_* macros don't do anything.
>
> On the other hand the VDSO library *does* use them, so user space can
> unwind through it.
>
> Make sure these macros only work for VDSO. They aren't actually being
> used outside of VDSO anyway, so there's no functional change.
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> ---
> arch/x86/include/asm/dwarf2.h | 51 ++++++++++++++++++++++++-----------
> 1 file changed, 35 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/include/asm/dwarf2.h b/arch/x86/include/asm/dwarf2.h
> index 09c9684d3ad6..7cc30500c095 100644
> --- a/arch/x86/include/asm/dwarf2.h
> +++ b/arch/x86/include/asm/dwarf2.h
> @@ -6,6 +6,15 @@
> #warning "asm/dwarf2.h should be only included in pure assembly files"
> #endif
>
> +#ifdef BUILD_VDSO
> +
> + /*
> + * For the vDSO, emit both runtime unwind information and debug
> + * symbols for the .dbg file.
> + */
> +
> + .cfi_sections .eh_frame, .debug_frame
> +
> #define CFI_STARTPROC .cfi_startproc
> #define CFI_ENDPROC .cfi_endproc
> #define CFI_DEF_CFA .cfi_def_cfa
> @@ -22,21 +31,31 @@
> #define CFI_ESCAPE .cfi_escape
> #define CFI_SIGNAL_FRAME .cfi_signal_frame
>
> -#ifndef BUILD_VDSO
> - /*
> - * Emit CFI data in .debug_frame sections, not .eh_frame sections.
> - * The latter we currently just discard since we don't do DWARF
> - * unwinding at runtime. So only the offline DWARF information is
> - * useful to anyone. Note we should not use this directive if we
> - * ever decide to enable DWARF unwinding at runtime.
> - */
> - .cfi_sections .debug_frame
> -#else
> - /*
> - * For the vDSO, emit both runtime unwind information and debug
> - * symbols for the .dbg file.
> - */
> - .cfi_sections .eh_frame, .debug_frame
> -#endif
> +#else /* !BUILD_VDSO */
> +
> +/*
> + * On x86, these macros aren't used outside VDSO. As well they shouldn't be:
> + * they're fragile and very difficult to maintain.
> + */
> +
> +.macro nocfi args:vararg
> +.endm
> +
> +#define CFI_STARTPROC nocfi
> +#define CFI_ENDPROC nocfi
> +#define CFI_DEF_CFA nocfi
> +#define CFI_DEF_CFA_REGISTER nocfi
> +#define CFI_DEF_CFA_OFFSET nocfi
> +#define CFI_ADJUST_CFA_OFFSET nocfi
> +#define CFI_OFFSET nocfi
> +#define CFI_REL_OFFSET nocfi
> +#define CFI_REGISTER nocfi
> +#define CFI_RESTORE nocfi
> +#define CFI_REMEMBER_STATE nocfi
> +#define CFI_RESTORE_STATE nocfi
> +#define CFI_UNDEFINED nocfi
> +#define CFI_ESCAPE nocfi
> +
> +#endif /* !BUILD_VDSO */
>
> #endif /* _ASM_X86_DWARF2_H */
I guess patch 3 justifies this.
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
^ permalink raw reply
* Re: [PATCH v7 4/6] x86/vdso: Use SYM_FUNC_{START,END} in __kernel_vsyscall()
From: H. Peter Anvin @ 2026-02-04 0:44 UTC (permalink / raw)
To: Jens Remus, linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
Liam R. Howlett, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Heiko Carstens,
Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-5-jremus@linux.ibm.com>
On 2026-02-03 09:19, Jens Remus wrote:
> From: Josh Poimboeuf <jpoimboe@kernel.org>
>
> Use SYM_FUNC_{START,END} instead of all the boilerplate. No functional
> change.
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> ---
>
> Notes (jremus):
> Changes in v7:
> - Rebase on H. Peter Anvin's vDSO changes on tip:x86/entry.
>
> arch/x86/entry/vdso/vdso32/system_call.S | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/entry/vdso/vdso32/system_call.S b/arch/x86/entry/vdso/vdso32/system_call.S
> index 9157cf9c5749..a90f4f7de396 100644
> --- a/arch/x86/entry/vdso/vdso32/system_call.S
> +++ b/arch/x86/entry/vdso/vdso32/system_call.S
> @@ -9,11 +9,7 @@
> #include <asm/alternative.h>
>
> .text
> - .globl __kernel_vsyscall
> - .type __kernel_vsyscall,@function
> - ALIGN
> -__kernel_vsyscall:
> - CFI_STARTPROC
> +SYM_FUNC_START(__kernel_vsyscall)
>
> /*
> * If using int $0x80, there is no reason to muck about with the
> @@ -85,7 +81,5 @@ SYM_INNER_LABEL(int80_landing_pad, SYM_L_GLOBAL)
> CFI_RESTORE ecx
> CFI_ADJUST_CFA_OFFSET -4
> RET
> - CFI_ENDPROC
> -
> - .size __kernel_vsyscall,.-__kernel_vsyscall
> +SYM_FUNC_END(__kernel_vsyscall)
> .previous
Looks good to me.
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
^ permalink raw reply
* Re: [PATCH v7 5/6] x86/vdso: Use CFI macros in __vdso_sgx_enter_enclave()
From: H. Peter Anvin @ 2026-02-04 0:44 UTC (permalink / raw)
To: Jens Remus, linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
Liam R. Howlett, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Heiko Carstens,
Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-6-jremus@linux.ibm.com>
On 2026-02-03 09:19, Jens Remus wrote:
> From: Josh Poimboeuf <jpoimboe@kernel.org>
>
> Use the CFI macros instead of the raw .cfi_* directives to be consistent
> with the rest of the VDSO asm. It's also easier on the eyes.
>
> No functional changes.
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> ---
> arch/x86/entry/vdso/vdso64/vsgx.S | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/entry/vdso/vdso64/vsgx.S b/arch/x86/entry/vdso/vdso64/vsgx.S
> index c0342238c976..8d7b8eb45c50 100644
> --- a/arch/x86/entry/vdso/vdso64/vsgx.S
> +++ b/arch/x86/entry/vdso/vdso64/vsgx.S
> @@ -24,13 +24,14 @@
> .section .text, "ax"
>
> SYM_FUNC_START(__vdso_sgx_enter_enclave)
> + SYM_F_ALIGN
> push %rbp
> - .cfi_adjust_cfa_offset 8
> - .cfi_rel_offset %rbp, 0
> + CFI_ADJUST_CFA_OFFSET 8
> + CFI_REL_OFFSET %rbp, 0
> mov %rsp, %rbp
> - .cfi_def_cfa_register %rbp
> + CFI_DEF_CFA_REGISTER %rbp
> push %rbx
> - .cfi_rel_offset %rbx, -8
> + CFI_REL_OFFSET %rbx, -8
>
> mov %ecx, %eax
> .Lenter_enclave:
> @@ -77,13 +78,11 @@ SYM_FUNC_START(__vdso_sgx_enter_enclave)
> .Lout:
> pop %rbx
> leave
> - .cfi_def_cfa %rsp, 8
> + CFI_DEF_CFA %rsp, 8
> RET
>
> - /* The out-of-line code runs with the pre-leave stack frame. */
> - .cfi_def_cfa %rbp, 16
> -
> .Linvalid_input:
> + CFI_DEF_CFA %rbp, 16
> mov $(-EINVAL), %eax
> jmp .Lout
>
Looks good to me.
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
^ permalink raw reply
* Re: [PATCH v7 6/6] x86/vdso: Enable sframe generation in VDSO
From: H. Peter Anvin @ 2026-02-04 0:49 UTC (permalink / raw)
To: Jens Remus, linux-kernel, linux-trace-kernel, bpf, x86, linux-mm,
Steven Rostedt
Cc: Josh Poimboeuf, Masami Hiramatsu, Mathieu Desnoyers,
Peter Zijlstra, Ingo Molnar, Jiri Olsa, Arnaldo Carvalho de Melo,
Namhyung Kim, Thomas Gleixner, Andrii Nakryiko, Indu Bhagat,
Jose E. Marchesi, Beau Belgrave, Linus Torvalds, Andrew Morton,
Florian Weimer, Kees Cook, Carlos O'Donell, Sam James,
Dylan Hatch, Borislav Petkov, Dave Hansen, David Hildenbrand,
Liam R. Howlett, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Suren Baghdasaryan, Vlastimil Babka, Heiko Carstens,
Vasily Gorbik, Steven Rostedt (Google)
In-Reply-To: <20260203171958.1522030-7-jremus@linux.ibm.com>
On 2026-02-03 09:19, Jens Remus wrote:
> -
> +#if defined(__x86_64__) && defined(CONFIG_AS_SFRAME)
> + .cfi_sections .eh_frame, .debug_frame, .sframe
> +#else
> .cfi_sections .eh_frame, .debug_frame
> +#endif
>
It would be better to:
#undef CONFIG_AS_SFRAME /* i386 doesn't support .sframe */
in fake_32bit_build.h.
-hpa
^ permalink raw reply
* Re: [PATCH v2] tracing: Fix funcgraph_exit calltime/rettime offset for 32-bit ARM
From: jempty.liang @ 2026-02-04 1:21 UTC (permalink / raw)
To: Steven Rostedt
Cc: mhiramat, mark.rutland, mathieu.desnoyers, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260203112040.01bbb8e9@gandalf.local.home>
At 2026-02-04 00:20:40, "Steven Rostedt" <rostedt@goodmis.org> wrote:
>On Tue, 3 Feb 2026 09:30:18 -0500
>Steven Rostedt <rostedt@goodmis.org> wrote:
>
>> > On the 32-bit ARM platform, when _type is unsigned long long, the resulting align value is 8 instead of the expected 4.
>> > >
>>
>> Are you saying this still doesn't work?
>>
>> That would be an issue because then it would have the same bugs with
>> generic trace events which uses the same solution.
>
>OK, so talking with others that know more about arm32 than I do, it can
>indeed still produce an 8 byte alignment.
>
>Anyway, I still want to fix it properly. Does this patch work for you?
>
>-- Steve
Yes, I've verified it and this patch works correctly on the 32-bit ARM platform.
>
>diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
>index b6d42fe06115..c11edec5d8f5 100644
>--- a/kernel/trace/trace.h
>+++ b/kernel/trace/trace.h
>@@ -68,14 +68,17 @@ enum trace_type {
> #undef __field_fn
> #define __field_fn(type, item) type item;
>
>+#undef __field_packed
>+#define __field_packed(type, item) type item;
>+
> #undef __field_struct
> #define __field_struct(type, item) __field(type, item)
>
> #undef __field_desc
> #define __field_desc(type, container, item)
>
>-#undef __field_packed
>-#define __field_packed(type, container, item)
>+#undef __field_desc_packed
>+#define __field_desc_packed(type, container, item)
>
> #undef __array
> #define __array(type, item, size) type item[size];
>diff --git a/kernel/trace/trace_entries.h b/kernel/trace/trace_entries.h
>index f6a8d29c0d76..54417468fdeb 100644
>--- a/kernel/trace/trace_entries.h
>+++ b/kernel/trace/trace_entries.h
>@@ -79,8 +79,8 @@ FTRACE_ENTRY(funcgraph_entry, ftrace_graph_ent_entry,
>
> F_STRUCT(
> __field_struct( struct ftrace_graph_ent, graph_ent )
>- __field_packed( unsigned long, graph_ent, func )
>- __field_packed( unsigned long, graph_ent, depth )
>+ __field_desc_packed(unsigned long, graph_ent, func )
>+ __field_desc_packed(unsigned long, graph_ent, depth )
> __dynamic_array(unsigned long, args )
> ),
>
>@@ -96,9 +96,9 @@ FTRACE_ENTRY_PACKED(fgraph_retaddr_entry, fgraph_retaddr_ent_entry,
>
> F_STRUCT(
> __field_struct( struct fgraph_retaddr_ent, graph_rent )
>- __field_packed( unsigned long, graph_rent.ent, func )
>- __field_packed( unsigned long, graph_rent.ent, depth )
>- __field_packed( unsigned long, graph_rent, retaddr )
>+ __field_desc_packed( unsigned long, graph_rent.ent, func )
>+ __field_desc_packed( unsigned long, graph_rent.ent, depth )
>+ __field_desc_packed( unsigned long, graph_rent, retaddr )
> __dynamic_array(unsigned long, args )
> ),
>
>@@ -123,12 +123,12 @@ FTRACE_ENTRY_PACKED(funcgraph_exit, ftrace_graph_ret_entry,
>
> F_STRUCT(
> __field_struct( struct ftrace_graph_ret, ret )
>- __field_packed( unsigned long, ret, func )
>- __field_packed( unsigned long, ret, retval )
>- __field_packed( unsigned int, ret, depth )
>- __field_packed( unsigned int, ret, overrun )
>- __field(unsigned long long, calltime )
>- __field(unsigned long long, rettime )
>+ __field_desc_packed( unsigned long, ret, func )
>+ __field_desc_packed( unsigned long, ret, retval )
>+ __field_desc_packed( unsigned int, ret, depth )
>+ __field_desc_packed( unsigned int, ret, overrun )
>+ __field_packed(unsigned long long, calltime)
>+ __field_packed(unsigned long long, rettime )
> ),
>
> F_printk("<-- %ps (%u) (start: %llx end: %llx) over: %u retval: %lx",
>@@ -146,11 +146,11 @@ FTRACE_ENTRY_PACKED(funcgraph_exit, ftrace_graph_ret_entry,
>
> F_STRUCT(
> __field_struct( struct ftrace_graph_ret, ret )
>- __field_packed( unsigned long, ret, func )
>- __field_packed( unsigned int, ret, depth )
>- __field_packed( unsigned int, ret, overrun )
>- __field(unsigned long long, calltime )
>- __field(unsigned long long, rettime )
>+ __field_desc_packed( unsigned long, ret, func )
>+ __field_desc_packed( unsigned int, ret, depth )
>+ __field_desc_packed( unsigned int, ret, overrun )
>+ __field_packed(unsigned long long, calltime )
>+ __field_packed(unsigned long long, rettime )
> ),
>
> F_printk("<-- %ps (%u) (start: %llx end: %llx) over: %u",
>diff --git a/kernel/trace/trace_export.c b/kernel/trace/trace_export.c
>index 1698fc22afa0..32a42ef31855 100644
>--- a/kernel/trace/trace_export.c
>+++ b/kernel/trace/trace_export.c
>@@ -42,11 +42,14 @@ static int ftrace_event_register(struct trace_event_call *call,
> #undef __field_fn
> #define __field_fn(type, item) type item;
>
>+#undef __field_packed
>+#define __field_packed(type, item) type item;
>+
> #undef __field_desc
> #define __field_desc(type, container, item) type item;
>
>-#undef __field_packed
>-#define __field_packed(type, container, item) type item;
>+#undef __field_desc_packed
>+#define __field_desc_packed(type, container, item) type item;
>
> #undef __array
> #define __array(type, item, size) type item[size];
>@@ -104,11 +107,14 @@ static void __always_unused ____ftrace_check_##name(void) \
> #undef __field_fn
> #define __field_fn(_type, _item) __field_ext(_type, _item, FILTER_TRACE_FN)
>
>+#undef __field_packed
>+#define __field_packed(_type, _item) __field_ext_packed(_type, _item, FILTER_OTHER)
>+
> #undef __field_desc
> #define __field_desc(_type, _container, _item) __field_ext(_type, _item, FILTER_OTHER)
>
>-#undef __field_packed
>-#define __field_packed(_type, _container, _item) __field_ext_packed(_type, _item, FILTER_OTHER)
>+#undef __field_desc_packed
>+#define __field_desc_packed(_type, _container, _item) __field_ext_packed(_type, _item, FILTER_OTHER)
>
> #undef __array
> #define __array(_type, _item, _len) { \
>@@ -146,11 +152,14 @@ static struct trace_event_fields ftrace_event_fields_##name[] = { \
> #undef __field_fn
> #define __field_fn(type, item)
>
>+#undef __field_packed
>+#define __field_packed(type, item)
>+
> #undef __field_desc
> #define __field_desc(type, container, item)
>
>-#undef __field_packed
>-#define __field_packed(type, container, item)
>+#undef __field_desc_packed
>+#define __field_desc_packed(type, container, item)
>
> #undef __array
> #define __array(type, item, len)
^ permalink raw reply
* [PATCH v5 0/3] Tracing: Accelerate Kernel Boot by Asynchronizing
From: Yaxiong Tian @ 2026-02-04 1:51 UTC (permalink / raw)
To: axboe, rostedt, mhiramat, mathieu.desnoyers
Cc: linux-block, linux-kernel, linux-trace-kernel, Yaxiong Tian
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 2745 bytes --]
On my ARM64 platform, I observed that certain tracing module
initializations run for up to 200ms—for example, init_kprobe_trace().
Analysis reveals the root cause: the execution flow eval_map_work_func()
→trace_event_update_with_eval_map()→trace_event_update_all()
is highly time-consuming. Although this flow is placed in eval_map_wq
for asynchronous execution, it holds the trace_event_sem lock, causing
other modules to be blocked either directly or indirectly. Also in
init_blk_tracer(), this functions require trace_event_sem device_initcall.
To resolve this issue, I rename `eval_map_wq` and make it global and moved
init_blk_tracer that are related to this lock to run asynchronously on this
workqueue. Also check for kprobe_event= grub parameter; if not provided,
init_kprobe_trace() returns directly. After optimization, boot time is
reduced by approximately 200ms.
Based on my analysis and testing, I've identified that only these two
locations significantly impact timing. Other initcall_* functions do not
exhibit relevant lock contention.
A brief summary of the test results is as follows:
Before this PATCHS:
[ 0.224933] calling init_kprobe_trace+0x0/0xe0 @ 1
[ 0.455016] initcall init_kprobe_trace+0x0/0xe0 returned 0 after 230080 usecs
Only opt setup_boot_kprobe_events() can see:
[ 0.258609] calling init_blk_tracer+0x0/0x68 @ 1
[ 0.454991] initcall init_blk_tracer+0x0/0x68 returned 0 after 196377 usecs
After this PATCHS:
[ 0.224940] calling init_kprobe_trace+0x0/0xe0 @ 1
[ 0.224946] initcall init_kprobe_trace+0x0/0xe0 returned 0 after 3 usecs
skip --------
[ 0.264835] calling init_blk_tracer+0x0/0x68 @ 1
[ 0.264841] initcall init_blk_tracer+0x0/0x68 returned 0 after 2 usecs
---
Changes in v2:
- Rename eval_map_wq to trace_init_wq.
Changes in v3:
- Opt PATCH 1/3 commit
Changes in v4:
- add trace_async_init boot parameter in patch2
- add init_kprobe_trace's skip logic in patch3
- add Suggested-by tag
- Other synchronous optimizations related to trace_async_init
https://lore.kernel.org/all/20260128125117.1704853-1-tianyaxiong@kylinos.cn/
Changes in v5:
- remove trace_async_init boot parameter (patch2 v4)
- remove make Make setup_boot_kprobe_events() asynchronous (patch4 v4)
- Adjusted the patch sequence.
Yaxiong Tian (3):
tracing: Rename `eval_map_wq` and allow other parts of tracing use it
blktrace: Make init_blk_tracer() asynchronous
tracing/kprobes: Skip setup_boot_kprobe_events() when no cmdline event
kernel/trace/blktrace.c | 23 ++++++++++++++++++++++-
kernel/trace/trace.c | 18 +++++++++---------
kernel/trace/trace.h | 1 +
kernel/trace/trace_kprobe.c | 4 ++++
4 files changed, 36 insertions(+), 10 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH v5 1/3] tracing: Rename `eval_map_wq` and allow other parts of tracing use it
From: Yaxiong Tian @ 2026-02-04 1:53 UTC (permalink / raw)
To: axboe, rostedt, mhiramat, mathieu.desnoyers
Cc: linux-block, linux-kernel, linux-trace-kernel, Yaxiong Tian
In-Reply-To: <20260204015103.155025-1-tianyaxiong@kylinos.cn>
The eval_map_work_func() function, though queued in eval_map_wq,
holds the trace_event_sem read-write lock for a long time during
kernel boot. This causes blocking issues for other functions.
Rename eval_map_wq to trace_init_wq and make it global, thereby
allowing other parts of tracing to schedule work on this queue
asynchronously and avoiding blockage of the main boot thread.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
---
kernel/trace/trace.c | 18 +++++++++---------
kernel/trace/trace.h | 1 +
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index b1cb30a7b83d..01df88e77818 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -10774,7 +10774,7 @@ int tracing_init_dentry(void)
extern struct trace_eval_map *__start_ftrace_eval_maps[];
extern struct trace_eval_map *__stop_ftrace_eval_maps[];
-static struct workqueue_struct *eval_map_wq __initdata;
+struct workqueue_struct *trace_init_wq __initdata;
static struct work_struct eval_map_work __initdata;
static struct work_struct tracerfs_init_work __initdata;
@@ -10790,15 +10790,15 @@ static int __init trace_eval_init(void)
{
INIT_WORK(&eval_map_work, eval_map_work_func);
- eval_map_wq = alloc_workqueue("eval_map_wq", WQ_UNBOUND, 0);
- if (!eval_map_wq) {
- pr_err("Unable to allocate eval_map_wq\n");
+ trace_init_wq = alloc_workqueue("trace_init_wq", WQ_UNBOUND, 0);
+ if (!trace_init_wq) {
+ pr_err("Unable to allocate trace_init_wq\n");
/* Do work here */
eval_map_work_func(&eval_map_work);
return -ENOMEM;
}
- queue_work(eval_map_wq, &eval_map_work);
+ queue_work(trace_init_wq, &eval_map_work);
return 0;
}
@@ -10807,8 +10807,8 @@ subsys_initcall(trace_eval_init);
static int __init trace_eval_sync(void)
{
/* Make sure the eval map updates are finished */
- if (eval_map_wq)
- destroy_workqueue(eval_map_wq);
+ if (trace_init_wq)
+ destroy_workqueue(trace_init_wq);
return 0;
}
@@ -10969,9 +10969,9 @@ static __init int tracer_init_tracefs(void)
if (ret)
return 0;
- if (eval_map_wq) {
+ if (trace_init_wq) {
INIT_WORK(&tracerfs_init_work, tracer_init_tracefs_work_func);
- queue_work(eval_map_wq, &tracerfs_init_work);
+ queue_work(trace_init_wq, &tracerfs_init_work);
} else {
tracer_init_tracefs_work_func(NULL);
}
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index de4e6713b84e..9e8d52503618 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -769,6 +769,7 @@ extern cpumask_var_t __read_mostly tracing_buffer_mask;
extern unsigned long nsecs_to_usecs(unsigned long nsecs);
extern unsigned long tracing_thresh;
+extern struct workqueue_struct *trace_init_wq __initdata;
/* PID filtering */
--
2.25.1
^ permalink raw reply related
* [PATCH v5 2/3] blktrace: Make init_blk_tracer() asynchronous
From: Yaxiong Tian @ 2026-02-04 1:53 UTC (permalink / raw)
To: axboe, rostedt, mhiramat, mathieu.desnoyers
Cc: linux-block, linux-kernel, linux-trace-kernel, Yaxiong Tian
In-Reply-To: <20260204015103.155025-1-tianyaxiong@kylinos.cn>
The init_blk_tracer() function causes significant boot delay as it
waits for the trace_event_sem lock held by trace_event_update_all().
Specifically, its child function register_trace_event() requires
this lock, which is occupied for an extended period during boot.
To resolve this, the execution of primary init_blk_tracer() is moved
to the trace_init_wq workqueue, allowing it to run asynchronously,
and prevent blocking the main boot thread.
Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
---
kernel/trace/blktrace.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
index d031c8d80be4..d611cd1f02ef 100644
--- a/kernel/trace/blktrace.c
+++ b/kernel/trace/blktrace.c
@@ -1832,7 +1832,9 @@ static struct trace_event trace_blk_event = {
.funcs = &trace_blk_event_funcs,
};
-static int __init init_blk_tracer(void)
+static struct work_struct blktrace_works __initdata;
+
+static int __init __init_blk_tracer(void)
{
if (!register_trace_event(&trace_blk_event)) {
pr_warn("Warning: could not register block events\n");
@@ -1852,6 +1854,25 @@ static int __init init_blk_tracer(void)
return 0;
}
+static void __init blktrace_works_func(struct work_struct *work)
+{
+ __init_blk_tracer();
+}
+
+static int __init init_blk_tracer(void)
+{
+ int ret = 0;
+
+ if (trace_init_wq) {
+ INIT_WORK(&blktrace_works, blktrace_works_func);
+ queue_work(trace_init_wq, &blktrace_works);
+ } else {
+ ret = __init_blk_tracer();
+ }
+
+ return ret;
+}
+
device_initcall(init_blk_tracer);
static int blk_trace_remove_queue(struct request_queue *q)
--
2.25.1
^ permalink raw reply related
* [PATCH v5 3/3] tracing/kprobes: Skip setup_boot_kprobe_events() when no cmdline event
From: Yaxiong Tian @ 2026-02-04 1:54 UTC (permalink / raw)
To: axboe, rostedt, mhiramat, mathieu.desnoyers
Cc: linux-block, linux-kernel, linux-trace-kernel, Yaxiong Tian
In-Reply-To: <20260204015103.155025-1-tianyaxiong@kylinos.cn>
When the 'kprobe_event=' kernel command-line parameter is not provided,
there is no need to execute setup_boot_kprobe_events().
This change optimizes the initialization function init_kprobe_trace()
by skipping unnecessary work and effectively prevents potential blocking
that could arise from contention on the event_mutex lock in subsequent
operations.
Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
---
kernel/trace/trace_kprobe.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 9953506370a5..89d2740f7bb5 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -2048,6 +2048,10 @@ static __init int init_kprobe_trace(void)
trace_create_file("kprobe_profile", TRACE_MODE_READ,
NULL, NULL, &kprobe_profile_ops);
+ /* If no 'kprobe_event=' cmd is provided, return directly. */
+ if (kprobe_boot_events_buf[0] == '\0')
+ return 0;
+
setup_boot_kprobe_events();
return 0;
--
2.25.1
^ permalink raw reply related
* Re: [RFC bpf-next 05/12] bpf: Add multi tracing attach types
From: Leon Hwang @ 2026-02-04 2:20 UTC (permalink / raw)
To: Jiri Olsa, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko
Cc: bpf, linux-trace-kernel, Martin KaFai Lau, Eduard Zingerman,
Song Liu, Yonghong Song, Menglong Dong, Steven Rostedt
In-Reply-To: <20260203093819.2105105-6-jolsa@kernel.org>
On 3/2/26 17:38, Jiri Olsa wrote:
> Adding new attach type to identify multi tracing attachment:
> BPF_TRACE_FENTRY_MULTI
> BPF_TRACE_FEXIT_MULTI
>
At this point, should we also introduce BPF_TRACE_FSESSION_MULTI
alongside BPF_TRACE_FENTRY_MULTI and BPF_TRACE_FEXIT_MULTI?
Thanks,
Leon
^ permalink raw reply
* Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Xu Yilun @ 2026-02-04 4:43 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Sean Christopherson, Ackerley Tng, Alexey Kardashevskiy, cgroups,
kvm, linux-doc, linux-fsdevel, linux-kernel, linux-kselftest,
linux-mm, linux-trace-kernel, x86, akpm, binbin.wu, bp, brauner,
chao.p.peng, chenhuacai, corbet, dave.hansen, dave.hansen, david,
dmatlack, erdemaktas, fan.du, fvdl, haibo1.xu, hannes, hch, hpa,
hughd, ira.weiny, isaku.yamahata, jack, james.morse, jarkko,
jgowans, jhubbard, jroedel, jthoughton, jun.miao, kai.huang,
keirf, kent.overstreet, liam.merwick, maciej.wieczor-retman, mail,
maobibo, mathieu.desnoyers, maz, mhiramat, mhocko, mic,
michael.roth, mingo, mlevitsk, mpe, muchun.song, nikunj, nsaenz,
oliver.upton, palmer, pankaj.gupta, paul.walmsley, pbonzini,
peterx, pgonda, prsampat, pvorel, qperret, richard.weiyang,
rick.p.edgecombe, rientjes, rostedt, roypat, rppt, shakeel.butt,
shuah, steven.price, steven.sistare, suzuki.poulose, tabba, tglx,
thomas.lendacky, vannapurve, vbabka, viro, vkuznets, wei.w.wang,
will, willy, wyihan, xiaoyao.li, yan.y.zhao, yilun.xu, yuzenghui,
zhiquan1.li
In-Reply-To: <20260203181618.GY2328995@ziepe.ca>
On Tue, Feb 03, 2026 at 02:16:18PM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 03, 2026 at 05:56:37PM +0800, Xu Yilun wrote:
> > > +1. For guest_memfd, we initially defined per-VM memory attributes to track
> > > private vs. shared. But as Ackerley noted, we are in the process of deprecating
> > > that support, e.g. by making it incompatible with various guest_memfd features,
> > > in favor of having each guest_memfd instance track the state of a given page.
> > >
> > > The original guest_memfd design was that it would _only_ hold private pages, and
> > > so tracking private vs. shared in guest_memfd didn't make any sense. As we've
> > > pivoted to in-place conversion, tracking private vs. shared in the guest_memfd
> > > has basically become mandatory. We could maaaaaybe make it work with per-VM
> > > attributes, but it would be insanely complex.
> > >
> > > For a dmabuf fd, the story is the same as guest_memfd. Unless private vs. shared
> > > is all or nothing, and can never change, then the only entity that can track that
> > > info is the owner of the dmabuf. And even if the private vs. shared attributes
> > > are constant, tracking it external to KVM makes sense, because then the provider
> > > can simply hardcode %true/%false.
> >
> > For CoCo-VM and Tee-IO, I'm wondering if host or KVM has to maintain
> > the private/shared attribute for "assigned MMIO". I'm not naming them
> > "host MMIO" cause unlike RAM host never needs to access them, either in
> > private manner or shared manner.
> >
> > Traditionally, host maps these MMIOs only because KVM needs HVA->HPA
> > mapping to find pfn and setup KVM MMU.
>
> This is not actually completely true, the host mapping still ends up
> being used by KVM if it happens to trap and emulate a MMIO touching
> instruction.
>
> It really shouldn't do this, but there is a whole set of complex
> machinery in KVM and qemu to handle this case.
>
> For example if the MSI-X window is not properly aligned then you have
> some MMIO that is trapped and must be reflected to real HW.
In this case, the affected pages are not assigned MMIOs and KVM won't
import them. Mapping them is just OK.
>
> So the sharable parts of the BAR should still end up being mmaped into
> userspace, I think.
This does mean we can't make VFIO totally unmappable. But VFIO can still
try to create unmappable dmabufs for assigned MMIO regions, fail dmabuf
creation or fail mmap() based on the addresses.
>
> Which means we need VFIO to know what they are, and hopefully it is
> just static based on the TDISP reports..
I don't think VMM need to check TDISP report. The only special thing is
the MSI-X mixed pages which can be figured out by standard PCI
discovery.
Seems this doesn't impact the idea that KVM needs no implication of
Private/Shared from VFIO, as long as VFIO keeps exported dmabufs
unmapped.
^ permalink raw reply
* [PATCH v2 0/2] bootconfig: Handle an empty value
From: Masami Hiramatsu (Google) @ 2026-02-04 8:33 UTC (permalink / raw)
To: Steven Rostedt, linux-trace-kernel; +Cc: Julius Werner, Masami Hiramatsu, LKML
This is the 2nd version of the update of the bootconfig parser to
make it handle an empty value which is terminated by a newline or
a comment. The previous version is here:
In this version I decided to make this change as an update instead
of a fix, since this can change the syntax rule which has been
accepted. In the previous change, it does not handle the array
correctly. This version fixes it[1/2].
Also, I added another patch to improve the test[2/2]. Previously
it just check the parse error, but it did not check whether the
good examples are formatted as it is expected. New test compares
the output so that we can ensure it is parsed as expected.
Thank you,
---
Masami Hiramatsu (Google) (2):
bootconfig: Terminate value search if it hits a newline
bootconfig: Check the parsed output of the good examples
.../samples/exp-good-array-space-comment.bconf | 1 +
.../samples/exp-good-comment-after-value.bconf | 1 +
.../bootconfig/samples/exp-good-mixed-append.bconf | 2 ++
tools/bootconfig/samples/exp-good-mixed-kv1.bconf | 2 ++
tools/bootconfig/samples/exp-good-mixed-kv2.bconf | 2 ++
tools/bootconfig/samples/exp-good-mixed-kv3.bconf | 5 +++++
.../samples/exp-good-mixed-override.bconf | 2 ++
tools/bootconfig/samples/exp-good-override.bconf | 4 ++++
tools/bootconfig/samples/exp-good-printables.bconf | 2 ++
tools/bootconfig/samples/exp-good-simple.bconf | 8 ++++++++
tools/bootconfig/samples/exp-good-single.bconf | 3 +++
.../samples/exp-good-space-after-value.bconf | 1 +
tools/bootconfig/samples/exp-good-tree.bconf | 8 ++++++++
.../samples/good-array-space-comment.bconf | 3 +--
tools/bootconfig/test-bootconfig.sh | 3 +++
15 files changed, 45 insertions(+), 2 deletions(-)
create mode 100644 tools/bootconfig/samples/exp-good-array-space-comment.bconf
create mode 100644 tools/bootconfig/samples/exp-good-comment-after-value.bconf
create mode 100644 tools/bootconfig/samples/exp-good-mixed-append.bconf
create mode 100644 tools/bootconfig/samples/exp-good-mixed-kv1.bconf
create mode 100644 tools/bootconfig/samples/exp-good-mixed-kv2.bconf
create mode 100644 tools/bootconfig/samples/exp-good-mixed-kv3.bconf
create mode 100644 tools/bootconfig/samples/exp-good-mixed-override.bconf
create mode 100644 tools/bootconfig/samples/exp-good-override.bconf
create mode 100644 tools/bootconfig/samples/exp-good-printables.bconf
create mode 100644 tools/bootconfig/samples/exp-good-simple.bconf
create mode 100644 tools/bootconfig/samples/exp-good-single.bconf
create mode 100644 tools/bootconfig/samples/exp-good-space-after-value.bconf
create mode 100644 tools/bootconfig/samples/exp-good-tree.bconf
--
Masami Hiramatsu (Google) <mhiramat@google.com>
^ permalink raw reply
* [PATCH v2 1/2] bootconfig: Terminate value search if it hits a newline
From: Masami Hiramatsu (Google) @ 2026-02-04 8:33 UTC (permalink / raw)
To: Steven Rostedt, linux-trace-kernel; +Cc: Julius Werner, Masami Hiramatsu, LKML
In-Reply-To: <177019401833.80694.554894321526842218.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Terminate the value search for a key if it hits a newline and make
the value empty.
When we pass a bootconfig with an empty value terminated by the
newline, like below::
foo =
bar = value
Current bootconfig interprets it as a single entry::
foo = "bar = value";
The Documentation/admin-guide/bootconfig.rst defines the value
itself is terminated by newline:
The value has to be terminated by semi-colon (``;``) or newline (``\n``).
but it does not define when the value search is terminated.
This changes the behavior to more line-oriented, so that it can
clear how it is working.
- The value search of key-value pair will be terminated by a comment
or newline.
- The value search of an array will continue beyond comments and
newlines.
Thus, with this update, the above example is interpreted as::
foo = "";
bar = "value";
And the below example will cause a syntax error because "bar" is expected
as a key but it has ','.
foo =
bar, buz
According to this change, one wrong example config is updated.
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
Changes in v2:
- Fix to handle multi-line array case correctly.
- Make this as a spec update, not fix.
---
| 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst
index 7a86042c9b6d..843b24b8de88 100644
--- a/Documentation/admin-guide/bootconfig.rst
+++ b/Documentation/admin-guide/bootconfig.rst
@@ -20,18 +20,26 @@ Config File Syntax
The boot config syntax is a simple structured key-value. Each key consists
of dot-connected-words, and key and value are connected by ``=``. The value
-has to be terminated by semi-colon (``;``) or newline (``\n``).
-For array value, array entries are separated by comma (``,``). ::
-
- KEY[.WORD[...]] = VALUE[, VALUE2[...]][;]
-
-Unlike the kernel command line syntax, spaces are OK around the comma and ``=``.
+string has to be terminated by the following delimiters described below.
Each key word must contain only alphabets, numbers, dash (``-``) or underscore
(``_``). And each value only contains printable characters or spaces except
for delimiters such as semi-colon (``;``), new-line (``\n``), comma (``,``),
hash (``#``) and closing brace (``}``).
+If the ``=`` is followed by whitespace up to one of these delimiters, the
+key is assigned an empty value.
+
+For arrays, the array values are comma (``,``) separated, and comments and
+line breaks with newline (``\n``) are allowed between array values for
+readability. Thus the first entry of the array must be the same line of the
+key.::
+
+ KEY[.WORD[...]] = VALUE[, VALUE2[...]][;]
+
+Unlike the kernel command line syntax, white spaces (including tabs) are
+ignored around the comma and ``=``.
+
If you want to use those delimiters in a value, you can use either double-
quotes (``"VALUE"``) or single-quotes (``'VALUE'``) to quote it. Note that
you can not escape these quotes.
@@ -138,8 +146,8 @@ This is parsed as below::
foo = value
bar = 1, 2, 3
-Note that you can not put a comment between value and delimiter(``,`` or
-``;``). This means following config has a syntax error ::
+Note that you can NOT put a comment or a newline between value and delimiter
+(``,`` or ``;``). This means following config has a syntax error ::
key = 1 # comment
,2
diff --git a/lib/bootconfig.c b/lib/bootconfig.c
index 81f29c29f47b..c210fb8b1e85 100644
--- a/lib/bootconfig.c
+++ b/lib/bootconfig.c
@@ -557,17 +557,13 @@ static int __init __xbc_close_brace(char *p)
/*
* Return delimiter or error, no node added. As same as lib/cmdline.c,
* you can use " around spaces, but can't escape " for value.
+ * *@__v must point real value string. (not including spaces before value.)
*/
static int __init __xbc_parse_value(char **__v, char **__n)
{
char *p, *v = *__v;
int c, quotes = 0;
- v = skip_spaces(v);
- while (*v == '#') {
- v = skip_comment(v);
- v = skip_spaces(v);
- }
if (*v == '"' || *v == '\'') {
quotes = *v;
v++;
@@ -617,6 +613,13 @@ static int __init xbc_parse_array(char **__v)
last_parent = xbc_node_get_child(last_parent);
do {
+ /* Search the next array value beyond comments and empty lines */
+ next = skip_spaces(*__v);
+ while (*next == '#') {
+ next = skip_comment(next);
+ next = skip_spaces(next);
+ }
+ *__v = next;
c = __xbc_parse_value(__v, &next);
if (c < 0)
return c;
@@ -701,9 +704,17 @@ static int __init xbc_parse_kv(char **k, char *v, int op)
if (ret)
return ret;
- c = __xbc_parse_value(&v, &next);
- if (c < 0)
- return c;
+ v = skip_spaces_until_newline(v);
+ /* If there is a comment, this has an mpty value. */
+ if (*v == '#') {
+ next = skip_comment(v);
+ *v = '\0';
+ c = '\n';
+ } else {
+ c = __xbc_parse_value(&v, &next);
+ if (c < 0)
+ return c;
+ }
child = xbc_node_get_child(last_parent);
if (child && xbc_node_is_value(child)) {
diff --git a/tools/bootconfig/samples/good-array-space-comment.bconf b/tools/bootconfig/samples/good-array-space-comment.bconf
index 45b938dc0695..416fa2ed4109 100644
--- a/tools/bootconfig/samples/good-array-space-comment.bconf
+++ b/tools/bootconfig/samples/good-array-space-comment.bconf
@@ -1,4 +1,3 @@
-key = # comment
- "value1", # comment1
+key = "value1", # comment1
"value2" , # comment2
"value3"
^ permalink raw reply related
* [PATCH v2 2/2] bootconfig: Check the parsed output of the good examples
From: Masami Hiramatsu (Google) @ 2026-02-04 8:33 UTC (permalink / raw)
To: Steven Rostedt, linux-trace-kernel; +Cc: Julius Werner, Masami Hiramatsu, LKML
In-Reply-To: <177019401833.80694.554894321526842218.stgit@devnote2>
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Check whether the parsed output of the good example configs are
the same as expected.
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
| 1 +
| 1 +
.../bootconfig/samples/exp-good-mixed-append.bconf | 2 ++
tools/bootconfig/samples/exp-good-mixed-kv1.bconf | 2 ++
tools/bootconfig/samples/exp-good-mixed-kv2.bconf | 2 ++
tools/bootconfig/samples/exp-good-mixed-kv3.bconf | 5 +++++
.../samples/exp-good-mixed-override.bconf | 2 ++
tools/bootconfig/samples/exp-good-override.bconf | 4 ++++
tools/bootconfig/samples/exp-good-printables.bconf | 2 ++
tools/bootconfig/samples/exp-good-simple.bconf | 8 ++++++++
tools/bootconfig/samples/exp-good-single.bconf | 3 +++
.../samples/exp-good-space-after-value.bconf | 1 +
tools/bootconfig/samples/exp-good-tree.bconf | 8 ++++++++
tools/bootconfig/test-bootconfig.sh | 3 +++
14 files changed, 44 insertions(+)
create mode 100644 tools/bootconfig/samples/exp-good-array-space-comment.bconf
create mode 100644 tools/bootconfig/samples/exp-good-comment-after-value.bconf
create mode 100644 tools/bootconfig/samples/exp-good-mixed-append.bconf
create mode 100644 tools/bootconfig/samples/exp-good-mixed-kv1.bconf
create mode 100644 tools/bootconfig/samples/exp-good-mixed-kv2.bconf
create mode 100644 tools/bootconfig/samples/exp-good-mixed-kv3.bconf
create mode 100644 tools/bootconfig/samples/exp-good-mixed-override.bconf
create mode 100644 tools/bootconfig/samples/exp-good-override.bconf
create mode 100644 tools/bootconfig/samples/exp-good-printables.bconf
create mode 100644 tools/bootconfig/samples/exp-good-simple.bconf
create mode 100644 tools/bootconfig/samples/exp-good-single.bconf
create mode 100644 tools/bootconfig/samples/exp-good-space-after-value.bconf
create mode 100644 tools/bootconfig/samples/exp-good-tree.bconf
--git a/tools/bootconfig/samples/exp-good-array-space-comment.bconf b/tools/bootconfig/samples/exp-good-array-space-comment.bconf
new file mode 100644
index 000000000000..8d3278fa6af5
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-array-space-comment.bconf
@@ -0,0 +1 @@
+key = "value1", "value2", "value3";
--git a/tools/bootconfig/samples/exp-good-comment-after-value.bconf b/tools/bootconfig/samples/exp-good-comment-after-value.bconf
new file mode 100644
index 000000000000..a8e8450db3c0
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-comment-after-value.bconf
@@ -0,0 +1 @@
+key = "value";
diff --git a/tools/bootconfig/samples/exp-good-mixed-append.bconf b/tools/bootconfig/samples/exp-good-mixed-append.bconf
new file mode 100644
index 000000000000..c2b407901ddd
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-mixed-append.bconf
@@ -0,0 +1,2 @@
+key = "foo", "bar";
+keyx.subkey = "value";
diff --git a/tools/bootconfig/samples/exp-good-mixed-kv1.bconf b/tools/bootconfig/samples/exp-good-mixed-kv1.bconf
new file mode 100644
index 000000000000..8346287d9251
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-mixed-kv1.bconf
@@ -0,0 +1,2 @@
+key = "value";
+key.subkey = "another-value";
diff --git a/tools/bootconfig/samples/exp-good-mixed-kv2.bconf b/tools/bootconfig/samples/exp-good-mixed-kv2.bconf
new file mode 100644
index 000000000000..40c6232c7cdd
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-mixed-kv2.bconf
@@ -0,0 +1,2 @@
+key = "another-value";
+key.subkey = "value";
diff --git a/tools/bootconfig/samples/exp-good-mixed-kv3.bconf b/tools/bootconfig/samples/exp-good-mixed-kv3.bconf
new file mode 100644
index 000000000000..8368a7bef60a
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-mixed-kv3.bconf
@@ -0,0 +1,5 @@
+key = "value";
+key {
+ subkey1;
+ subkey2 = "foo";
+}
diff --git a/tools/bootconfig/samples/exp-good-mixed-override.bconf b/tools/bootconfig/samples/exp-good-mixed-override.bconf
new file mode 100644
index 000000000000..58757712ca45
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-mixed-override.bconf
@@ -0,0 +1,2 @@
+key = "value2";
+key.foo = "bar";
diff --git a/tools/bootconfig/samples/exp-good-override.bconf b/tools/bootconfig/samples/exp-good-override.bconf
new file mode 100644
index 000000000000..00bbd30e99ae
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-override.bconf
@@ -0,0 +1,4 @@
+key {
+ word = "2", "3";
+ new.word = "new";
+}
diff --git a/tools/bootconfig/samples/exp-good-printables.bconf b/tools/bootconfig/samples/exp-good-printables.bconf
new file mode 100644
index 000000000000..5981d304eacb
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-printables.bconf
@@ -0,0 +1,2 @@
+key = "
+\v\f !#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~";
diff --git a/tools/bootconfig/samples/exp-good-simple.bconf b/tools/bootconfig/samples/exp-good-simple.bconf
new file mode 100644
index 000000000000..d17f39421c86
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-simple.bconf
@@ -0,0 +1,8 @@
+key {
+ word1 = "1";
+ word2 = "2";
+ word3 = "3";
+ word4 = "4";
+ word5 = "5";
+ word6 = "6";
+}
diff --git a/tools/bootconfig/samples/exp-good-single.bconf b/tools/bootconfig/samples/exp-good-single.bconf
new file mode 100644
index 000000000000..01196910d7f4
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-single.bconf
@@ -0,0 +1,3 @@
+key = "1";
+key2 = "2";
+key3 = "alpha", "beta";
diff --git a/tools/bootconfig/samples/exp-good-space-after-value.bconf b/tools/bootconfig/samples/exp-good-space-after-value.bconf
new file mode 100644
index 000000000000..a8e8450db3c0
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-space-after-value.bconf
@@ -0,0 +1 @@
+key = "value";
diff --git a/tools/bootconfig/samples/exp-good-tree.bconf b/tools/bootconfig/samples/exp-good-tree.bconf
new file mode 100644
index 000000000000..b711d38d86fd
--- /dev/null
+++ b/tools/bootconfig/samples/exp-good-tree.bconf
@@ -0,0 +1,8 @@
+key {
+ word.tree.value = "0";
+ word2.tree.value = "1", "2";
+}
+other.tree {
+ value = "2";
+ value2 = "3";
+}
diff --git a/tools/bootconfig/test-bootconfig.sh b/tools/bootconfig/test-bootconfig.sh
index 7594659af1e1..be9bd18b1d56 100755
--- a/tools/bootconfig/test-bootconfig.sh
+++ b/tools/bootconfig/test-bootconfig.sh
@@ -179,6 +179,9 @@ done
echo "=== expected success cases ==="
for i in samples/good-* ; do
xpass $BOOTCONF -a $i $INITRD
+ x="samples/exp-"`basename $i`
+ $BOOTCONF $i > $TEMPCONF
+ xpass diff $x $TEMPCONF
done
^ permalink raw reply related
* Re: [PATCH v5 0/3] Tracing: Accelerate Kernel Boot by Asynchronizing
From: Masami Hiramatsu @ 2026-02-04 10:15 UTC (permalink / raw)
To: Yaxiong Tian
Cc: axboe, rostedt, mathieu.desnoyers, linux-block, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260204015103.155025-1-tianyaxiong@kylinos.cn>
On Wed, 4 Feb 2026 09:51:03 +0800
Yaxiong Tian <tianyaxiong@kylinos.cn> wrote:
> On my ARM64 platform, I observed that certain tracing module
> initializations run for up to 200ms—for example, init_kprobe_trace().
> Analysis reveals the root cause: the execution flow eval_map_work_func()
> →trace_event_update_with_eval_map()→trace_event_update_all()
> is highly time-consuming. Although this flow is placed in eval_map_wq
> for asynchronous execution, it holds the trace_event_sem lock, causing
> other modules to be blocked either directly or indirectly. Also in
> init_blk_tracer(), this functions require trace_event_sem device_initcall.
>
> To resolve this issue, I rename `eval_map_wq` and make it global and moved
> init_blk_tracer that are related to this lock to run asynchronously on this
> workqueue. Also check for kprobe_event= grub parameter; if not provided,
> init_kprobe_trace() returns directly. After optimization, boot time is
> reduced by approximately 200ms.
>
>
> Based on my analysis and testing, I've identified that only these two
> locations significantly impact timing. Other initcall_* functions do not
> exhibit relevant lock contention.
>
> A brief summary of the test results is as follows:
> Before this PATCHS:
> [ 0.224933] calling init_kprobe_trace+0x0/0xe0 @ 1
> [ 0.455016] initcall init_kprobe_trace+0x0/0xe0 returned 0 after 230080 usecs
>
> Only opt setup_boot_kprobe_events() can see:
> [ 0.258609] calling init_blk_tracer+0x0/0x68 @ 1
> [ 0.454991] initcall init_blk_tracer+0x0/0x68 returned 0 after 196377 usecs
>
> After this PATCHS:
> [ 0.224940] calling init_kprobe_trace+0x0/0xe0 @ 1
> [ 0.224946] initcall init_kprobe_trace+0x0/0xe0 returned 0 after 3 usecs
> skip --------
> [ 0.264835] calling init_blk_tracer+0x0/0x68 @ 1
> [ 0.264841] initcall init_blk_tracer+0x0/0x68 returned 0 after 2 usecs
Looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thanks!
>
> ---
> Changes in v2:
> - Rename eval_map_wq to trace_init_wq.
> Changes in v3:
> - Opt PATCH 1/3 commit
> Changes in v4:
> - add trace_async_init boot parameter in patch2
> - add init_kprobe_trace's skip logic in patch3
> - add Suggested-by tag
> - Other synchronous optimizations related to trace_async_init
> https://lore.kernel.org/all/20260128125117.1704853-1-tianyaxiong@kylinos.cn/
> Changes in v5:
> - remove trace_async_init boot parameter (patch2 v4)
> - remove make Make setup_boot_kprobe_events() asynchronous (patch4 v4)
> - Adjusted the patch sequence.
>
>
> Yaxiong Tian (3):
> tracing: Rename `eval_map_wq` and allow other parts of tracing use it
> blktrace: Make init_blk_tracer() asynchronous
> tracing/kprobes: Skip setup_boot_kprobe_events() when no cmdline event
>
> kernel/trace/blktrace.c | 23 ++++++++++++++++++++++-
> kernel/trace/trace.c | 18 +++++++++---------
> kernel/trace/trace.h | 1 +
> kernel/trace/trace_kprobe.c | 4 ++++
> 4 files changed, 36 insertions(+), 10 deletions(-)
>
> --
> 2.25.1
>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [RFC bpf-next 01/12] ftrace: Add ftrace_hash_count function
From: Jiri Olsa @ 2026-02-04 12:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, bpf,
linux-trace-kernel, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Menglong Dong
In-Reply-To: <20260203104032.582709b7@gandalf.local.home>
On Tue, Feb 03, 2026 at 10:40:32AM -0500, Steven Rostedt wrote:
> On Tue, 3 Feb 2026 10:38:08 +0100
> Jiri Olsa <jolsa@kernel.org> wrote:
>
> > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> > index 705db0a6d995..6dade0eaee46 100644
> > --- a/include/linux/ftrace.h
> > +++ b/include/linux/ftrace.h
> > @@ -413,6 +413,7 @@ struct ftrace_hash *alloc_ftrace_hash(int size_bits);
> > void free_ftrace_hash(struct ftrace_hash *hash);
> > struct ftrace_func_entry *add_ftrace_hash_entry_direct(struct ftrace_hash *hash,
> > unsigned long ip, unsigned long direct);
> > +unsigned long ftrace_hash_count(struct ftrace_hash *hash);
> >
> > /* The hash used to know what functions callbacks trace */
> > struct ftrace_ops_hash {
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index b12dbd93ae1c..be9e0ac1fd95 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -6284,7 +6284,7 @@ int modify_ftrace_direct(struct ftrace_ops *ops, unsigned long addr)
> > }
> > EXPORT_SYMBOL_GPL(modify_ftrace_direct);
> >
> > -static unsigned long hash_count(struct ftrace_hash *hash)
> > +unsigned long ftrace_hash_count(struct ftrace_hash *hash)
> > {
> > return hash ? hash->count : 0;
> > }
>
> I think this may make it less likely to inline this function, so let's just
> add an external function, and even add a "inline" to the original:
>
> static inline unsigned long hash_count(struct ftrace_hash *hash)
> {
> return hash ? hash->count : 0;
> }
>
> unsigned long ftrace_hash_count(struct ftrace_hash *hash)
> {
> return hash_count(hash);
> }
>
> And don't modify anything else.
ok, will change
thanks,
jirka
^ permalink raw reply
* Re: [RFC bpf-next 00/12] bpf: tracing_multi link
From: Jiri Olsa @ 2026-02-04 12:36 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, bpf,
linux-trace-kernel, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Menglong Dong, Steven Rostedt
In-Reply-To: <CAADnVQ+EU_f4LVDQkqkB0Q+QYMBH5ynXU3+rGZA2XCGmYMcFqg@mail.gmail.com>
On Tue, Feb 03, 2026 at 03:17:05PM -0800, Alexei Starovoitov wrote:
> On Tue, Feb 3, 2026 at 1:38 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > hi,
> > as an option to Meglong's change [1] I'm sending proposal for tracing_multi
> > link that does not add static trampoline but attaches program to all needed
> > trampolines.
> >
> > This approach keeps the same performance but has some drawbacks:
> >
> > - when attaching 20k functions we allocate and attach 20k trampolines
> > - during attachment we hold each trampoline mutex, so for above
> > 20k functions we will hold 20k mutexes during the attachment,
> > should be very prone to deadlock, but haven't hit it yet
>
> If you check that it's sorted and always take them in the same order
> then there will be no deadlock.
> Or just grab one global mutex first and then grab trampolines mutexes
> next in any order. The global one will serialize this attach operation.
>
> > It looks the trampoline allocations/generation might not be big a problem
> > and I'll try to find a solution for holding that many mutexes. If there's
> > no better solution I think having one read/write mutex for tracing multi
> > link attach/detach should work.
>
> If you mean to have one global mutex as I proposed above then I don't see
> a downside. It only serializes multiple libbpf calls.
we also need to serialize it with standard single trampoline attach,
because the direct ftrace update is now done under trampoline->mutex:
bpf_trampoline_link_prog(tr)
{
mutex_lock(&tr->mutex);
...
update_ftrace_direct_*
...
mutex_unlock(&tr->mutex);
}
for tracing_multi we would link the program first (with tr->mutex)
and do the bulk ftrace update later (without tr->mutex)
{
for each involved trampoline:
bpf_trampoline_link_prog
--> and here we could race with some other thread doing single
trampoline attach
update_ftrace_direct_*
}
note the current version locks all tr->mutex instances all the way
through the update_ftrace_direct_* update
I think we could use global rwsem and take read lock on single
trampoline attach path and write lock on tracing_multi attach,
I thought we could take direct_mutex early, but that would mean
different order with trampoline mutex than we already have in
single attach path
or just sort those btf ids
jirka
^ permalink raw reply
* Re: [RFC bpf-next 05/12] bpf: Add multi tracing attach types
From: Jiri Olsa @ 2026-02-04 12:41 UTC (permalink / raw)
To: Leon Hwang
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, bpf,
linux-trace-kernel, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, Menglong Dong, Steven Rostedt
In-Reply-To: <3015991d-2e9b-4bf4-9c17-26e00b5d5926@linux.dev>
On Wed, Feb 04, 2026 at 10:20:29AM +0800, Leon Hwang wrote:
>
>
> On 3/2/26 17:38, Jiri Olsa wrote:
> > Adding new attach type to identify multi tracing attachment:
> > BPF_TRACE_FENTRY_MULTI
> > BPF_TRACE_FEXIT_MULTI
> >
> At this point, should we also introduce BPF_TRACE_FSESSION_MULTI
> alongside BPF_TRACE_FENTRY_MULTI and BPF_TRACE_FEXIT_MULTI?
good catch, will add it
thanks,
jirka
^ permalink raw reply
* Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Jason Gunthorpe @ 2026-02-04 12:47 UTC (permalink / raw)
To: Xu Yilun
Cc: Sean Christopherson, Ackerley Tng, Alexey Kardashevskiy, cgroups,
kvm, linux-doc, linux-fsdevel, linux-kernel, linux-kselftest,
linux-mm, linux-trace-kernel, x86, akpm, binbin.wu, bp, brauner,
chao.p.peng, chenhuacai, corbet, dave.hansen, dave.hansen, david,
dmatlack, erdemaktas, fan.du, fvdl, haibo1.xu, hannes, hch, hpa,
hughd, ira.weiny, isaku.yamahata, jack, james.morse, jarkko,
jgowans, jhubbard, jroedel, jthoughton, jun.miao, kai.huang,
keirf, kent.overstreet, liam.merwick, maciej.wieczor-retman, mail,
maobibo, mathieu.desnoyers, maz, mhiramat, mhocko, mic,
michael.roth, mingo, mlevitsk, mpe, muchun.song, nikunj, nsaenz,
oliver.upton, palmer, pankaj.gupta, paul.walmsley, pbonzini,
peterx, pgonda, prsampat, pvorel, qperret, richard.weiyang,
rick.p.edgecombe, rientjes, rostedt, roypat, rppt, shakeel.butt,
shuah, steven.price, steven.sistare, suzuki.poulose, tabba, tglx,
thomas.lendacky, vannapurve, vbabka, viro, vkuznets, wei.w.wang,
will, willy, wyihan, xiaoyao.li, yan.y.zhao, yilun.xu, yuzenghui,
zhiquan1.li
In-Reply-To: <aYLOZIZU0nwk+0UN@yilunxu-OptiPlex-7050>
On Wed, Feb 04, 2026 at 12:43:16PM +0800, Xu Yilun wrote:
> > Which means we need VFIO to know what they are, and hopefully it is
> > just static based on the TDISP reports..
>
> I don't think VMM need to check TDISP report. The only special thing is
> the MSI-X mixed pages which can be figured out by standard PCI
> discovery.
Either that or follow along with the guests's choices on
shared/private.
We can't let VFIO mmap a private MMIO page, so it has to know which
pages are private at any moment, and it can't guess.
Jason
^ permalink raw reply
* Re: [PATCH] [v2] tracing: move __printf() attribute on __ftrace_vbprintk()
From: Andy Shevchenko @ 2026-02-04 13:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Steven Rostedt, Masami Hiramatsu, Anna Schumaker, Jeff Layton,
Chuck Lever, Simon Horman, Arnd Bergmann, Mathieu Desnoyers,
Andrew Morton, Yury Norov, Randy Dunlap, linux-kernel,
linux-trace-kernel
In-Reply-To: <20260203164545.3174910-1-arnd@kernel.org>
On Tue, Feb 03, 2026 at 05:45:29PM +0100, Arnd Bergmann wrote:
> The sunrpc change to use trace_printk() for debugging caused
> a new warning for every instance of dprintk() in some configurations,
> when -Wformat-security is enabled:
>
> fs/nfs/getroot.c: In function 'nfs_get_root':
> fs/nfs/getroot.c:90:17: error: format not a string literal and no format arguments [-Werror=format-security]
> 90 | nfs_errorf(fc, "NFS: Couldn't getattr on root");
>
> I've been slowly chipping away at those warnings over time with the
> intention of enabling them by default in the future. While I could not
> figure out why this only happens for this one instance, I see that the
> __trace_bprintk() function is always called with a local variable as
> the format string, rather than a literal.
>
> Move the __printf(2,3) annotation on this function from the declaration
> to the caller. As this is can only be validated for literals, the
> attribute on the declaration causes the warnings every time, but
> removing it entirely introduces a new warning on the __ftrace_vbprintk()
> definition.
>
> The format strings still get checked because the underlying literal keeps
> getting passed into __trace_printk() in the "else" branch, which is not
> taken but still evaluated for compile-time warnings.
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox