* [PATCH v2] selftests/ftrace: Fix trace_marker_raw test on 64K page kernels
From: Tianchen Ding @ 2026-05-28 2:24 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Shuah Khan
Cc: linux-kernel, linux-trace-kernel, linux-kselftest
In-Reply-To: <20260527095438.1794905-1-dtcccc@linux.alibaba.com>
On ARM64 kernels with 64K pages, the trace_marker_raw test fails because
bash's printf builtin uses stdio buffering which splits output into
multiple small write() calls to the tracefs file. Since each individual
write is within TRACE_MARKER_MAX_SIZE (4096), they all succeed, causing
the "too big" write test to incorrectly pass.
Fix by piping make_str output through dd with iflag=fullblock to
guarantee a single atomic write() syscall to trace_marker_raw.
Fixes: 37f46601383a ("selftests/tracing: Add basic test for trace_marker_raw file")
Signed-off-by: Tianchen Ding <dtcccc@linux.alibaba.com>
---
v2:
Update comment about 64K pages.
---
.../selftests/ftrace/test.d/00basic/trace_marker_raw.tc | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/ftrace/test.d/00basic/trace_marker_raw.tc b/tools/testing/selftests/ftrace/test.d/00basic/trace_marker_raw.tc
index 8e905d4fe6dd..f68f1901f65f 100644
--- a/tools/testing/selftests/ftrace/test.d/00basic/trace_marker_raw.tc
+++ b/tools/testing/selftests/ftrace/test.d/00basic/trace_marker_raw.tc
@@ -43,8 +43,11 @@ write_buffer() {
id=$1
size=$2
- # write the string into the raw marker
- make_str $id $size > trace_marker_raw
+ # Pipe through dd to ensure a single atomic write() syscall
+ # on architectures with 64K pages, where shell's printf builtin
+ # uses stdio buffering which may split the output into multiple
+ # writes.
+ make_str $id $size | dd of=trace_marker_raw bs=`expr $size + 4` iflag=fullblock
}
--
2.39.3
^ permalink raw reply related
* Re: [PATCH bpf-next] x86/ftrace: relocate %rip-relative percpu refs in dynamic trampolines
From: Peter Zijlstra @ 2026-05-27 21:11 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation)
Cc: Steven Rostedt, Masami Hiramatsu, Mark Rutland, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Uros Bizjak, Thomas Petazzoni, Ingo Molnar, linux-kernel,
linux-trace-kernel, bpf, ebpf, Bastien Curutchet
In-Reply-To: <20260527-fix_call_depth_in_trampoline-v1-1-1c1abc8ae310@bootlin.com>
On Wed, May 27, 2026 at 09:12:31PM +0200, Alexis Lothoré (eBPF Foundation) wrote:
> With CONFIG_CALL_DEPTH_TRACKING enabled on an x86 retbleed-affected
> platform (eg: Skylake), with retbleed=stuff, registering a dynamic
> ftrace trampoline crashes on the first call into the traced function:
>
>
> This small reproducer allows to easily trigger the crash:
>
> # echo 'p __x64_sys_clock_nanosleep' > /sys/kernel/tracing/kprobe_events
> # echo 1 > /sys/kernel/tracing/events/kprobes/p___x64_sys_clock_nanosleep_0/enable
> # usleep 1
>
> Monitoring the crash under GDB points to the exact instruction in charge
> of incrementing the call depth:
>
> sarq $5, %gs:__x86_call_depth(%rip)
>
> This instruction matches the one inserted by the ftrace_regs_caller from
> ftrace_64.S. This emitted code was likely working fine until the
> introduction of commit 59bec00ace28 ("x86/percpu: Introduce
> %rip-relative addressing to PER_CPU_VAR()"): it has made the call depth
> accounting addressing relative to $rip, instead of being based on an
> absolute address. As this code exact location depends on where the
> trampoline lives in memory, the corresponding displacement needs to be
> adjusted at runtime to actually correctly find the per-cpu
> __x86_call_depth value, otherwise the targeted address is wrong, leading
> to the page fault seen above.
>
> Fix the %rip-relative displacement of the copied CALL_DEPTH_ACCOUNT
> instruction (from ftrace_regs_caller) by calling
> text_poke_apply_relocation(), as it is done for example by the x86 BPF
> JIT compiler through x86_call_depth_emit_accounting(). This corrects
> both CALL_DEPTH_ACCOUNT slots, in ftrace_caller and ftrace_regs_caller.
>
> Fixes: 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()")
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> arch/x86/kernel/ftrace.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index 0543b57f54ee..357df1b2922c 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -375,6 +375,13 @@ create_trampoline(struct ftrace_ops *ops, unsigned int *tramp_size)
> goto fail;
> }
>
> + /*
> + * Generated trampoline may contain rip-relative addressing which
> + * displacement needs to be fixed
> + */
> + text_poke_apply_relocation(trampoline, trampoline, size,
> + (void *)start_offset, size);
> +
> /*
> * The address of the ftrace_ops that is used for this trampoline
> * is stored at the end of the trampoline. This will be used to
I went and had a quick grep through the tree to see if there are more
sites that were missed in the conversion (commit 17bce3b2ae2d), but I
couldn't find another one.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
^ permalink raw reply
* Re: [PATCH v16 03/20] unwind_user/sframe: Store .sframe section data in per-mm maple tree
From: Steven Rostedt @ 2026-05-27 20:20 UTC (permalink / raw)
To: Jens Remus
Cc: linux-kernel, linux-trace-kernel, x86, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Dylan Hatch, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
Mathieu Desnoyers, Kees Cook, Sam James, bpf, linux-mm,
Namhyung Kim, Andrii Nakryiko, Jose E. Marchesi, Beau Belgrave,
Florian Weimer, Carlos O'Donell, Masami Hiramatsu, Jiri Olsa,
Arnaldo Carvalho de Melo, Andrew Morton, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Heiko Carstens, Vasily Gorbik,
Ilya Leoshkevich, Steven Rostedt (Google)
In-Reply-To: <20260521142546.3908498-4-jremus@linux.ibm.com>
On Thu, 21 May 2026 16:25:29 +0200
Jens Remus <jremus@linux.ibm.com> wrote:
> int sframe_remove_section(unsigned long sframe_start)
> {
> - return -ENOSYS;
> + struct mm_struct *mm = current->mm;
> + struct sframe_section *sec;
> + unsigned long index = 0;
> + bool found = false;
> + int ret = 0;
> +
> + guard(srcu)(&sframe_srcu);
> +
> + mt_for_each(&mm->sframe_mt, sec, index, ULONG_MAX) {
> + if (sec->sframe_start == sframe_start) {
> + found = true;
> + ret |= __sframe_remove_section(mm, sec);
Because this is all internal data, the __sframe_remove_section() should
never fail. Perhaps we should add a WARN_ON() if it does?
if (sec->sframe_start == sframe_start) {
ret |= __sframe_remove_section(mm, sec);
WARN_ON(!found && ret);
found = true;
-- Steve
> + }
> + }
> +
> + if (!found || ret)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
^ permalink raw reply
* Re: [PATCH v16 02/20] unwind_user/sframe: Add support for reading .sframe headers
From: Steven Rostedt @ 2026-05-27 20:09 UTC (permalink / raw)
To: Jens Remus
Cc: linux-kernel, linux-trace-kernel, x86, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Dylan Hatch, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, H. Peter Anvin,
Mathieu Desnoyers, Kees Cook, Sam James, bpf, linux-mm,
Namhyung Kim, Andrii Nakryiko, Jose E. Marchesi, Beau Belgrave,
Florian Weimer, Carlos O'Donell, Masami Hiramatsu, Jiri Olsa,
Arnaldo Carvalho de Melo, Andrew Morton, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Heiko Carstens, Vasily Gorbik,
Ilya Leoshkevich, Steven Rostedt (Google)
In-Reply-To: <20260521142546.3908498-3-jremus@linux.ibm.com>
On Thu, 21 May 2026 16:25:28 +0200
Jens Remus <jremus@linux.ibm.com> wrote:
> +static int sframe_read_header(struct sframe_section *sec)
> +{
> + unsigned long header_end, fdes_start, fdes_end, fres_start, fres_end;
> + struct sframe_header shdr;
> + unsigned int num_fdes;
> +
> + if (copy_from_user(&shdr, (void __user *)sec->sframe_start, sizeof(shdr))) {
> + dbg("header usercopy failed\n");
> + return -EFAULT;
> + }
> +
> + if (shdr.preamble.magic != SFRAME_MAGIC ||
> + shdr.preamble.version != SFRAME_VERSION_3 ||
> + !(shdr.preamble.flags & SFRAME_F_FDE_SORTED) ||
> + !(shdr.preamble.flags & SFRAME_F_FDE_FUNC_START_PCREL) ||
> + shdr.auxhdr_len) {
> + dbg("bad/unsupported sframe header\n");
> + return -EINVAL;
> + }
> +
> + if (!shdr.num_fdes || !shdr.num_fres) {
> + dbg("no fde/fre entries\n");
> + return -EINVAL;
> + }
> +
> + header_end = sec->sframe_start + SFRAME_HEADER_SIZE(shdr);
> + if (header_end >= sec->sframe_end) {
> + dbg("header doesn't fit in section\n");
> + return -EINVAL;
> + }
> +
> + num_fdes = shdr.num_fdes;
> + fdes_start = header_end + shdr.fdes_off;
> + fdes_end = fdes_start + (num_fdes * sizeof(struct sframe_fde_v3));
> +
> + fres_start = header_end + shdr.fres_off;
> + fres_end = fres_start + shdr.fre_len;
> +
> + if (fres_start < fdes_end || fres_end > sec->sframe_end) {
> + dbg("inconsistent fde/fre offsets\n");
> + return -EINVAL;
> + }
I really think we should also test if fres_start >= fres_end. Because
if fres_start is near sec->sframe_end and on 32bit archs fre_len makes
fres_end overflow, this doesn't catch it.
Even if it doesn't cause issues later, I rather have it caught here.
-- Steve
> +
> + sec->num_fdes = num_fdes;
> + sec->fdes_start = fdes_start;
> + sec->fres_start = fres_start;
> + sec->fres_end = fres_end;
> +
> + sec->ra_off = shdr.cfa_fixed_ra_offset;
> + sec->fp_off = shdr.cfa_fixed_fp_offset;
> +
> + return 0;
> +}
^ permalink raw reply
* Re: [PATCH 6.12] x86/fgraph: Fix return_to_handler regs.rsp value
From: Sasha Levin @ 2026-05-27 19:49 UTC (permalink / raw)
To: stable, gregkh
Cc: Sasha Levin, jolsa, rostedt, mhiramat, tglx, mingo, bp, x86,
linux-trace-kernel, bpf, Andrii Nakryiko, Gyokhan Kochmarla
In-Reply-To: <20260526192324.79459-1-gyokhan@amazon.de>
> commit 8bc11700e0d23d4fdb7d8d5a73b2e95de427cabc upstream.
Queued for 6.12.y, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 6.12] tracing: Fix the bug where bpf_get_stackid returns -EFAULT on the ARM64
From: Sasha Levin @ 2026-05-27 19:49 UTC (permalink / raw)
To: stable, gregkh
Cc: Sasha Levin, yangfeng, rostedt, mhiramat, mark.rutland,
catalin.marinas, will, jolsa, linux-trace-kernel,
linux-arm-kernel, bpf, Gyokhan Kochmarla
In-Reply-To: <20260526192012.76223-1-gyokhan@amazon.de>
> commit fd2f74f8f3d3c1a524637caf5bead9757fae4332 upstream.
>
> When using bpf_program__attach_kprobe_multi_opts on ARM64 to hook a BPF program
> that contains the bpf_get_stackid function, the BPF program fails
> to obtain the stack trace and returns -EFAULT.
Queued for 6.12.y, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v8 0/6] mm/memory-failure: add panic option for unrecoverable pages
From: Andrew Morton @ 2026-05-27 19:39 UTC (permalink / raw)
To: Breno Leitao
Cc: Miaohe Lin, David Hildenbrand, Lorenzo Stoakes, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, Shuah Khan,
Naoya Horiguchi, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Liam R. Howlett,
linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team, Lance Yang
In-Reply-To: <20260527-ecc_panic-v8-0-9ea0cfa16bb0@debian.org>
On Wed, 27 May 2026 07:06:13 -0700 Breno Leitao <leitao@debian.org> wrote:
> A multi-bit ECC error on a kernel-owned page that the memory failure
> handler cannot recover is currently swallowed: PG_hwpoison is set, the
> event is logged, and the kernel keeps running. The corrupted memory
> remains accessible to the kernel and either drives silent data
> corruption or surfaces seconds-to-minutes later as an apparently
> unrelated crash. In a large fleet that delayed, unattributable crash
> turns into significant engineering effort to root-cause; in a kdump
> configuration, by the time the crash happens the original error
> context (faulting PFN, MCE/GHES record, page state) is long gone.
>
> This series adds an opt-in sysctl,
> vm.panic_on_unrecoverable_memory_failure, that converts an
> unrecoverable kernel-page hwpoison event into an immediate panic with
> a clean dmesg/vmcore that still contains the original failure
> context. The default is disabled so existing workloads see no
> change.
Thanks. That does seem useful.
I'll pass at this time, due to -rc5 and not-very-reviewed.
AI review said a few things. It claims to have found one pre-existing
issue.
https://sashiko.dev/#/patchset/20260527-ecc_panic-v8-0-9ea0cfa16bb0@debian.org
^ permalink raw reply
* Re: [PATCH v2] scripts: Have make TAGS not include structure members
From: Masatake YAMATO @ 2026-05-27 19:36 UTC (permalink / raw)
To: peterz
Cc: rostedt, linux-kernel, linux-trace-kernel, linux-kbuild, akpm,
masahiroy, geert, mmarek, hamo.by, sboyd
In-Reply-To: <20260527162914.GH3102624@noisy.programming.kicks-ass.net>
From: Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2] scripts: Have make TAGS not include structure members
Date: Wed, 27 May 2026 18:29:14 +0200
> On Wed, May 27, 2026 at 12:11:44PM -0400, Steven Rostedt wrote:
>> From: Steven Rostedt <rostedt@goodmis.org>
>>
>> It is really annoying when I use emacs TAGS to search for something
>> like "dev_name" and have to go through 12 iterations before I find the
>> function "dev_name". I really do not care about structures that include
>> "dev_name" as one of its fields, and I'm sure pretty much all other
>> developers do not care either.
>>
>> There's a "remove_structs" variable used by the scripts/tags.sh, which
>> I'm guessing is suppose to remove these structures from the TAGS file,
>> but it must do a poor job at it, as I'm always hitting structures when
>> I want the actual declaration.
>>
>> Luckily, the etags program comes with an option "--no-members", which does
>> exactly what I want, and I'm sure all other kernel developers want too.
>>
>> Create a new "no_members" variable and assign it to "--no-members" for the
>> "TAGS" case and pass that to the etags program to remove structures.
>>
>> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
>> ---
>> Changes since v1: https://lore.kernel.org/all/20131115093645.6dc03918@gandalf.local.home/
>>
>> - Use a no_members variable instead of hard coding the --no-members into
>> the etags call, as that can break some "tags" cases. (Michal Marek)
>
> Yeah, I often use member tags.
>
> The tags file have a 'kind' field, what you want is for emacs to order
> on kind and prefer 'f' over 'm'.
citre (https://github.com/universal-ctags/citre) utilizes the kinds field
of tags file when soriting the list of definitions. citre runs on emacs.
https://github.com/universal-ctags/citre/blob/master/citre-lang-c.el#L28 explains
the parts of heuristics used in citre:
;; - When the symbol is after "->" or ".", tags of member kind are sorted above
;; others.
;; - When the symbol is before "(", tags of function/macro kinds are sorted
;; above others.
;; - When the cursor is on the header file in a "#include" directive, the
;; header file itself, and the references to that header file (if tagged) is
;; found as its definitions. References that uses paths can't be found.
;; Also, file names will be used for auto-completion.
I use citre and ctags daily for reading kernel code. Quite comfortable.
Masatake YAMATO
>
> The alternative is switching to use emacs-lsp, that way the editor knows
> the kind of symbol you want. If you're on a function call, it should
> only consider 'f' tags. Whereas if the cursor is on a member deref, it
> should only consider 'm'.
>
^ permalink raw reply
* Re: [PATCH bpf-next] x86/ftrace: relocate %rip-relative percpu refs in dynamic trampolines
From: Steven Rostedt @ 2026-05-27 19:30 UTC (permalink / raw)
To: Alexis Lothoré
Cc: Masami Hiramatsu, Mark Rutland, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Uros Bizjak,
Thomas Petazzoni, Ingo Molnar, linux-kernel, linux-trace-kernel,
bpf, ebpf, Bastien Curutchet
In-Reply-To: <DITPAGA18EUH.26LNYC9K9KX1P@bootlin.com>
On Wed, 27 May 2026 21:19:47 +0200
Alexis Lothoré <alexis.lothore@bootlin.com> wrote:
> On Wed May 27, 2026 at 9:08 PM CEST, Alexis Lothoré (eBPF Foundation) wrote:
>
> [...]
>
> > Fixes: 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()")
> > Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
>
> Please ignore the 'bpf-next' target for the patch, this is a mistake (I
> used my bpf tree to prepare this patch), I am really targeting the trace
> tree here.
Actually, it should go through the x86 tree.
Acked-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH bpf-next] x86/ftrace: relocate %rip-relative percpu refs in dynamic trampolines
From: Alexis Lothoré @ 2026-05-27 19:19 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation), Steven Rostedt,
Masami Hiramatsu, Mark Rutland, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Uros Bizjak
Cc: Thomas Petazzoni, Ingo Molnar, linux-kernel, linux-trace-kernel,
bpf, ebpf, Bastien Curutchet
In-Reply-To: <20260527-fix_call_depth_in_trampoline-v1-1-d0292bfe7eed@bootlin.com>
On Wed May 27, 2026 at 9:08 PM CEST, Alexis Lothoré (eBPF Foundation) wrote:
[...]
> Fixes: 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()")
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
Please ignore the 'bpf-next' target for the patch, this is a mistake (I
used my bpf tree to prepare this patch), I am really targeting the trace
tree here.
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH bpf-next] x86/ftrace: relocate %rip-relative percpu refs in dynamic trampolines
From: Alexis Lothoré (eBPF Foundation) @ 2026-05-27 19:12 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mark Rutland, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Uros Bizjak
Cc: Thomas Petazzoni, Ingo Molnar, linux-kernel, linux-trace-kernel,
bpf, ebpf, Bastien Curutchet,
Alexis Lothoré (eBPF Foundation)
With CONFIG_CALL_DEPTH_TRACKING enabled on an x86 retbleed-affected
platform (eg: Skylake), with retbleed=stuff, registering a dynamic
ftrace trampoline crashes on the first call into the traced function:
[ 9.630365] BUG: unable to handle page fault for address: ffff88817ae18880
[ 9.630365] #PF: supervisor write access in kernel mode
[ 9.630365] #PF: error_code(0x0002) - not-present page
[ 9.630365] PGD 4b53067 P4D 4b53067 PUD 0
[ 9.630365] Oops: Oops: 0002 [#1] SMP PTI
[ 9.630365] CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full)
[ 9.630365] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014
[ 9.630365] RIP: 0010:0xffffffffc0400058
[ 9.630365] Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89
[ 9.630365] RSP: 0018:ffffc90000a3fe60 EFLAGS: 00010382
[ 9.630365] RAX: ffffffffffffffff RBX: ffffc90000a3ff58 RCX: 0000000000000000
[ 9.630365] RDX: ffffc90000a3ff48 RSI: ffffffff82198e40 RDI: ffffffff813f5654
[ 9.630365] RBP: ffffc90000a3ff48 R08: 0000000000000000 R09: 0000000000000000
[ 9.630365] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8881030d3780
[ 9.630365] R13: 00000000000000e6 R14: 0000000000000000 R15: 0000000000000000
[ 9.630365] FS: 00007f081d131740(0000) GS:ffff8881b7eae000(0000) knlGS:0000000000000000
[ 9.630365] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9.630365] CR2: ffff88817ae18880 CR3: 00000001033dc006 CR4: 00000000003706f0
[ 9.630365] Call Trace:
[ 9.630365] <TASK>
[ 9.630365] ? find_held_lock+0x2b/0x80
[ 9.630365] ? exc_page_fault+0x74/0x220
[ 9.630365] ? lock_release+0xe1/0x320
[ 9.630365] ? __x64_sys_clock_nanosleep+0x9/0x1a0
[ 9.630365] ? lockdep_hardirqs_on_prepare+0xd9/0x190
[ 9.630365] ? trace_hardirqs_on+0x18/0x100
[ 9.630365] __x64_sys_clock_nanosleep+0x9/0x1a0
[ 9.630365] do_syscall_64+0x100/0x5f0
[ 9.630365] ? exc_page_fault+0x1e0/0x220
[ 9.630365] ? call_depth_return_thunk+0x2a/0xd0
[ 9.630365] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 9.630365] RIP: 0033:0x7f081d20ad83
[ 9.630365] Code: ff ff c3 0f 1f 40 00 83 ff 03 74 7b 83 ff 02 b8 fa ff ff ff 49 89 ca 0f 44 f8 80 3d c6 d2 10 00 00 74 14 b8 e6 00 00 00 0f 05 <f7> d8 c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec 28 48 89 54 24 10
[ 9.630365] RSP: 002b:00007ffd539e1328 EFLAGS: 00000202 ORIG_RAX: 00000000000000e6
[ 9.630365] RAX: ffffffffffffffda RBX: 0000000000000103 RCX: 00007f081d20ad83
[ 9.630365] RDX: 00007ffd539e1340 RSI: 0000000000000000 RDI: 0000000000000000
[ 9.630365] RBP: 00007ffd539e14f8 R08: 0000000000000000 R09: 0000000000000000
[ 9.630365] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
[ 9.630365] R13: 00007ffd539e1510 R14: 00007f081d370000 R15: 00005619c9d78338
[ 9.630365] </TASK>
[ 9.630365] Modules linked in:
[ 9.630365] CR2: ffff88817ae18880
[ 9.630365] ---[ end trace 0000000000000000 ]---
[ 9.630365] RIP: 0010:0xffffffffc0400058
[ 9.630365] Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89
[ 9.630365] RSP: 0018:ffffc90000a3fe60 EFLAGS: 00010382
[ 9.630365] RAX: ffffffffffffffff RBX: ffffc90000a3ff58 RCX: 0000000000000000
[ 9.630365] RDX: ffffc90000a3ff48 RSI: ffffffff82198e40 RDI: ffffffff813f5654
[ 9.630365] RBP: ffffc90000a3ff48 R08: 0000000000000000 R09: 0000000000000000
[ 9.630365] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8881030d3780
[ 9.630365] R13: 00000000000000e6 R14: 0000000000000000 R15: 0000000000000000
[ 9.630365] FS: 00007f081d131740(0000) GS:ffff8881b7eae000(0000) knlGS:0000000000000000
[ 9.630365] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9.630365] CR2: ffff88817ae18880 CR3: 00000001033dc006 CR4: 00000000003706f0
[ 9.630365] Kernel panic - not syncing: Fatal exception
This small reproducer allows to easily trigger the crash:
# echo 'p __x64_sys_clock_nanosleep' > /sys/kernel/tracing/kprobe_events
# echo 1 > /sys/kernel/tracing/events/kprobes/p___x64_sys_clock_nanosleep_0/enable
# usleep 1
Monitoring the crash under GDB points to the exact instruction in charge
of incrementing the call depth:
sarq $5, %gs:__x86_call_depth(%rip)
This instruction matches the one inserted by the ftrace_regs_caller from
ftrace_64.S. This emitted code was likely working fine until the
introduction of commit 59bec00ace28 ("x86/percpu: Introduce
%rip-relative addressing to PER_CPU_VAR()"): it has made the call depth
accounting addressing relative to $rip, instead of being based on an
absolute address. As this code exact location depends on where the
trampoline lives in memory, the corresponding displacement needs to be
adjusted at runtime to actually correctly find the per-cpu
__x86_call_depth value, otherwise the targeted address is wrong, leading
to the page fault seen above.
Fix the %rip-relative displacement of the copied CALL_DEPTH_ACCOUNT
instruction (from ftrace_regs_caller) by calling
text_poke_apply_relocation(), as it is done for example by the x86 BPF
JIT compiler through x86_call_depth_emit_accounting(). This corrects
both CALL_DEPTH_ACCOUNT slots, in ftrace_caller and ftrace_regs_caller.
Fixes: 59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PER_CPU_VAR()")
Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
---
arch/x86/kernel/ftrace.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 0543b57f54ee..357df1b2922c 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -375,6 +375,13 @@ create_trampoline(struct ftrace_ops *ops, unsigned int *tramp_size)
goto fail;
}
+ /*
+ * Generated trampoline may contain rip-relative addressing which
+ * displacement needs to be fixed
+ */
+ text_poke_apply_relocation(trampoline, trampoline, size,
+ (void *)start_offset, size);
+
/*
* The address of the ftrace_ops that is used for this trampoline
* is stored at the end of the trampoline. This will be used to
---
base-commit: aef70d0806e39b83f1fbecc32c72cc328751292a
change-id: 20260527-fix_call_depth_in_trampoline-80bc56930c8f
Best regards,
--
Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
^ permalink raw reply related
* Re: [PATCH v2] scripts: Have make TAGS not include structure members
From: Steven Rostedt @ 2026-05-27 18:47 UTC (permalink / raw)
To: Peter Zijlstra
Cc: LKML, Linux trace kernel, linux-kbuild, Andrew Morton,
Masahiro Yamada, Masatake YAMATO, Geert Uytterhoeven,
Michal Marek, Yang Bai
In-Reply-To: <20260527162914.GH3102624@noisy.programming.kicks-ass.net>
On Wed, 27 May 2026 18:29:14 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> Yeah, I often use member tags.
>
> The tags file have a 'kind' field, what you want is for emacs to order
> on kind and prefer 'f' over 'm'.
>
> The alternative is switching to use emacs-lsp, that way the editor knows
> the kind of symbol you want. If you're on a function call, it should
> only consider 'f' tags. Whereas if the cursor is on a member deref, it
> should only consider 'm'.
OK, so in addition to my procrastination of sending out this patch, I
finally changed my .emacs file to have "Meta-." call
xref-find-definitions instead of find-tags.
The xref-find-definitions gives a list of all the tags it finds and you
can search for the function. In the example of "dev_name", I simply
searched for "dev_name(" and it found the function immediately.
As "find-tags" has been deprecated back in 2016 (10 years ago!), and
xref-find-definitions doesn't suffer as much as 'find-tags' does with
respect to member tags. I'll simply drop this patch.
I can also finally archive the conversation I have in my INBOX! ;-)
-- Steve
^ permalink raw reply
* [PATCH 3/4] bootconfig: add xbc_prepend_embedded_cmdline() helper
From: Breno Leitao @ 2026-05-27 16:41 UTC (permalink / raw)
To: Masami Hiramatsu, Andrew Morton, Nathan Chancellor, paulmck,
Nicolas Schier
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, linux-kernel, linux-trace-kernel, linux-kbuild,
bpf, Breno Leitao, kernel-team
In-Reply-To: <20260527-bootconfig_using_tools-v1-0-b6906a86e7d5@debian.org>
Add a helper that prepends the build-time-rendered embedded bootconfig
"kernel" subtree (embedded_kernel_cmdline[] from embedded-cmdline.S) to
a cmdline buffer with a separating space. Architectures call this from
setup_arch() before parse_early_param() so early_param() handlers
(mem=, earlycon=, loglevel=, ...) see values supplied via the embedded
bootconfig.
On overflow the helper logs an error and leaves the cmdline untouched
rather than panicking. Booting without the embedded values is better
than refusing to boot, and the error tells the user why their embedded
keys are missing.
When CONFIG_BOOT_CONFIG_EMBED_CMDLINE=n, the public declaration in
<linux/bootconfig.h> resolves to a no-op stub so callers compile
unchanged.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
include/linux/bootconfig.h | 7 +++++++
lib/bootconfig.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/include/linux/bootconfig.h b/include/linux/bootconfig.h
index 1c7f3b74ffcf..dcb0c86cbc54 100644
--- a/include/linux/bootconfig.h
+++ b/include/linux/bootconfig.h
@@ -308,4 +308,11 @@ static inline const char *xbc_get_embedded_bootconfig(size_t *size)
}
#endif
+/* Build-time-rendered bootconfig cmdline prepended in setup_arch() */
+#ifdef CONFIG_BOOT_CONFIG_EMBED_CMDLINE
+void __init xbc_prepend_embedded_cmdline(char *dst, size_t size);
+#else
+static inline void xbc_prepend_embedded_cmdline(char *dst, size_t size) { }
+#endif
+
#endif
diff --git a/lib/bootconfig.c b/lib/bootconfig.c
index 3a102c9122f7..10c62c8600c8 100644
--- a/lib/bootconfig.c
+++ b/lib/bootconfig.c
@@ -19,6 +19,7 @@
#include <linux/errno.h>
#include <linux/cache.h>
#include <linux/compiler.h>
+#include <linux/printk.h>
#include <linux/sprintf.h>
#include <linux/memblock.h>
#include <linux/string.h>
@@ -34,6 +35,53 @@ const char * __init xbc_get_embedded_bootconfig(size_t *size)
return (*size) ? embedded_bootconfig_data : NULL;
}
#endif
+
+#ifdef CONFIG_BOOT_CONFIG_EMBED_CMDLINE
+/* embedded_kernel_cmdline is defined in embedded-cmdline.S */
+extern __visible const char embedded_kernel_cmdline[];
+extern __visible const char embedded_kernel_cmdline_end[];
+
+/**
+ * xbc_prepend_embedded_cmdline() - Prepend embedded bootconfig cmdline
+ * @dst: cmdline buffer to prepend into (must already contain a NUL byte)
+ * @size: total capacity of @dst in bytes
+ *
+ * Prepend the build-time-rendered "kernel" subtree of the embedded
+ * bootconfig to @dst. The rendered string already ends with a single
+ * space (the xbc_snprint_cmdline() invariant), which serves as the
+ * separator between the embedded keys and any existing content of @dst.
+ * On overflow, log an error and leave @dst untouched rather than
+ * silently truncating: booting without the embedded values is better
+ * than refusing to boot, and the error message tells the user why
+ * their embedded keys are missing.
+ *
+ * Intended to be called from setup_arch() before parse_early_param() so
+ * that early_param() handlers see the embedded values.
+ */
+void __init xbc_prepend_embedded_cmdline(char *dst, size_t size)
+{
+ size_t embed_len = embedded_kernel_cmdline_end - embedded_kernel_cmdline;
+ size_t dst_len;
+
+ if (!size || embed_len <= 1) /* trailing NUL only */
+ return;
+ embed_len--; /* exclude trailing NUL byte */
+
+ dst_len = strnlen(dst, size);
+ if (embed_len + dst_len + 1 > size) {
+ pr_err("embedded bootconfig cmdline (%zu bytes) does not fit in COMMAND_LINE_SIZE with %zu bytes already used; ignoring embedded values\n",
+ embed_len, dst_len);
+ return;
+ }
+
+ if (dst_len)
+ memmove(dst + embed_len, dst, dst_len + 1);
+ else
+ dst[embed_len] = '\0';
+ memcpy(dst, embedded_kernel_cmdline, embed_len);
+}
+#endif
+
#endif
/*
--
2.54.0
^ permalink raw reply related
* [PATCH 4/4] x86/setup: prepend embedded bootconfig cmdline before parse_early_param
From: Breno Leitao @ 2026-05-27 16:41 UTC (permalink / raw)
To: Masami Hiramatsu, Andrew Morton, Nathan Chancellor, paulmck,
Nicolas Schier
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, linux-kernel, linux-trace-kernel, linux-kbuild,
bpf, Breno Leitao, kernel-team
In-Reply-To: <20260527-bootconfig_using_tools-v1-0-b6906a86e7d5@debian.org>
Call xbc_prepend_embedded_cmdline() in setup_arch() right after the
CONFIG_CMDLINE merge and before strscpy(command_line, ...) so the
build-time-rendered embedded bootconfig "kernel" subtree is part of
boot_command_line by the time parse_early_param() runs. early_param()
handlers (mem=, earlycon=, loglevel=, ...) now see values supplied via
CONFIG_BOOT_CONFIG_EMBED_FILE without parsing bootconfig at runtime.
Select ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG so the user-visible
CONFIG_BOOT_CONFIG_EMBED_CMDLINE option becomes selectable on x86.
With this select in place, setup_boot_config() in init/main.c would
otherwise render the embedded "kernel" subtree a second time via
xbc_make_cmdline("kernel") and prepend it to saved_command_line /
static_command_line through extra_command_line, duplicating every
embedded kernel.* key in /proc/cmdline and causing accumulating
handlers (console=, earlycon=, ...) to register the same value twice.
Track whether the bootconfig data came from the embedded source and
skip the duplicate render in that case.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/x86/Kconfig | 1 +
arch/x86/kernel/setup.c | 3 +++
init/main.c | 19 ++++++++++++++++---
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f24810015234..f839795692b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -126,6 +126,7 @@ config X86
select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
select ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP if NR_CPUS <= 4096
select ARCH_SUPPORTS_CFI if X86_64
+ select ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG
select ARCH_USES_CFI_TRAPS if X86_64 && CFI
select ARCH_SUPPORTS_LTO_CLANG
select ARCH_SUPPORTS_LTO_CLANG_THIN
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 46882ce79c3a..592c4c79c974 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -6,6 +6,7 @@
* parts of early kernel initialization.
*/
#include <linux/acpi.h>
+#include <linux/bootconfig.h>
#include <linux/console.h>
#include <linux/cpu.h>
#include <linux/crash_dump.h>
@@ -924,6 +925,8 @@ void __init setup_arch(char **cmdline_p)
builtin_cmdline_added = true;
#endif
+ xbc_prepend_embedded_cmdline(boot_command_line, COMMAND_LINE_SIZE);
+
strscpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
diff --git a/init/main.c b/init/main.c
index e363232b428b..8264bfa97aa2 100644
--- a/init/main.c
+++ b/init/main.c
@@ -378,12 +378,15 @@ static void __init setup_boot_config(void)
int pos, ret;
size_t size;
char *err;
+ bool from_embedded = false;
/* Cut out the bootconfig data even if we have no bootconfig option */
data = get_boot_config_from_initrd(&size);
/* If there is no bootconfig in initrd, try embedded one. */
- if (!data)
+ if (!data) {
data = xbc_get_embedded_bootconfig(&size);
+ from_embedded = true;
+ }
strscpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
err = parse_args("bootconfig", tmp_cmdline, NULL, 0, 0, 0, NULL,
@@ -421,8 +424,18 @@ static void __init setup_boot_config(void)
} else {
xbc_get_info(&ret, NULL);
pr_info("Load bootconfig: %ld bytes %d nodes\n", (long)size, ret);
- /* keys starting with "kernel." are passed via cmdline */
- extra_command_line = xbc_make_cmdline("kernel");
+ /*
+ * keys starting with "kernel." are passed via cmdline. When
+ * BOOT_CONFIG_EMBED_CMDLINE is enabled and this bootconfig
+ * came from the embedded source, setup_arch() already
+ * prepended the rendered "kernel" subtree to
+ * boot_command_line; rendering again here would duplicate
+ * the keys in saved_command_line / static_command_line and
+ * cause accumulating handlers (console=, earlycon=, ...) to
+ * re-register the same value.
+ */
+ if (!IS_ENABLED(CONFIG_BOOT_CONFIG_EMBED_CMDLINE) || !from_embedded)
+ extra_command_line = xbc_make_cmdline("kernel");
/* Also, "init." keys are init arguments */
extra_init_args = xbc_make_cmdline("init");
}
--
2.54.0
^ permalink raw reply related
* [PATCH 2/4] bootconfig: render embedded bootconfig as a kernel cmdline at build time
From: Breno Leitao @ 2026-05-27 16:41 UTC (permalink / raw)
To: Masami Hiramatsu, Andrew Morton, Nathan Chancellor, paulmck,
Nicolas Schier
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, linux-kernel, linux-trace-kernel, linux-kbuild,
bpf, Breno Leitao, kernel-team
In-Reply-To: <20260527-bootconfig_using_tools-v1-0-b6906a86e7d5@debian.org>
Add the build-time pipeline that renders the "kernel" subtree of
CONFIG_BOOT_CONFIG_EMBED_FILE into a flat cmdline string and stashes
it in .init.rodata as embedded_kernel_cmdline[]. A follow-up patch
adds the runtime helper that prepends this string to boot_command_line
during early architecture setup so parse_early_param() sees the values.
The build wires up:
tools/bootconfig -C kernel - userspace tool already shared with
lib/bootconfig.c, used here in -C mode
to render a bootconfig file to a cmdline
lib/embedded-cmdline.S - .incbin's the rendered text plus a NUL
lib/Makefile rule - runs tools/bootconfig at build time
Makefile prepare dep - ensures tools/bootconfig is built first,
same pattern as tools/objtool and
tools/bpf/resolve_btfids
Drop the test target from tools/bootconfig/Makefile's default 'all'
recipe so that hooking the binary into the kernel build does not run
test-bootconfig.sh on every prepare. The tests stay available as
'make -C tools/bootconfig test', matching the convention of
tools/objtool and tools/bpf/resolve_btfids whose 'all' targets only
build the binary.
Require BOOT_CONFIG_EMBED_FILE to be non-empty before the new option
can be enabled, otherwise tools/bootconfig -C runs against an empty
file and prints a parse error on every kernel build.
The feature gates on CONFIG_ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG, a
silent symbol arches select once they've wired the prepend call into
setup_arch(). No arch selects it in this patch, so the user-visible
CONFIG_BOOT_CONFIG_EMBED_CMDLINE is not yet enableable; when an arch
later opts in, the runtime behavior is added by the follow-up patches.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Makefile | 5 +++++
init/Kconfig | 33 +++++++++++++++++++++++++++++++++
lib/Makefile | 16 ++++++++++++++++
lib/embedded-cmdline.S | 16 ++++++++++++++++
tools/bootconfig/Makefile | 2 +-
5 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index d59f703f9797..3ee259d00a9a 100644
--- a/Makefile
+++ b/Makefile
@@ -1543,6 +1543,11 @@ prepare: tools/bpf/resolve_btfids
endif
endif
+# lib/Makefile invokes tools/bootconfig to render the embedded bconf to cmdline.
+ifdef CONFIG_BOOT_CONFIG_EMBED_CMDLINE
+prepare: tools/bootconfig
+endif
+
# The tools build system is not a part of Kbuild and tends to introduce
# its own unique issues. If you need to integrate a new tool into Kbuild,
# please consider locating that tool outside the tools/ tree and using the
diff --git a/init/Kconfig b/init/Kconfig
index ca35184532dc..5f491a5ac4b8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1569,6 +1569,39 @@ config BOOT_CONFIG_EMBED_FILE
This bootconfig will be used if there is no initrd or no other
bootconfig in the initrd.
+config ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG
+ bool
+ help
+ Selected by architectures whose setup_arch() prepends the
+ build-time-rendered embedded bootconfig cmdline to
+ boot_command_line before parse_early_param() runs.
+
+config BOOT_CONFIG_EMBED_CMDLINE
+ bool "Render embedded bootconfig as kernel cmdline at build time"
+ depends on BOOT_CONFIG_EMBED
+ depends on BOOT_CONFIG_EMBED_FILE != ""
+ depends on ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG
+ default n
+ help
+ Render the "kernel" subtree of the embedded bootconfig file into a
+ flat cmdline string at kernel build time and prepend it to
+ boot_command_line during early architecture setup. This makes
+ early_param() handlers (e.g. mem=, earlycon=, loglevel=) see the
+ values supplied via the embedded bootconfig.
+
+ The runtime bootconfig parser is unaffected, so tree-structured
+ consumers such as ftrace boot-time tracing keep working.
+
+ Note: when an initrd also carries a bootconfig, its "kernel"
+ subtree is still parsed at runtime, but the embedded "kernel"
+ keys remain in boot_command_line for parse_early_param() and
+ end up later than the initrd keys in saved_command_line, so
+ parse_args() last-wins favors the embedded values. If you need
+ initrd to override embedded kernel.* keys, leave this option
+ off.
+
+ If unsure, say N.
+
config CMDLINE_LOG_WRAP_IDEAL_LEN
int "Length to try to wrap the cmdline when logged at boot"
default 1021
diff --git a/lib/Makefile b/lib/Makefile
index 6e72d2c1cce7..9de0ac7732a2 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -273,6 +273,22 @@ filechk_defbconf = cat $(or $(real-prereqs), /dev/null)
$(obj)/default.bconf: $(CONFIG_BOOT_CONFIG_EMBED_FILE) FORCE
$(call filechk,defbconf)
+obj-$(CONFIG_BOOT_CONFIG_EMBED_CMDLINE) += embedded-cmdline.o
+$(obj)/embedded-cmdline.o: $(obj)/embedded_cmdline.bin
+
+# Render the bootconfig "kernel" subtree to a flat cmdline string using
+# the userspace tools/bootconfig parser (-C mode). The runtime prepend
+# helper enforces COMMAND_LINE_SIZE at boot, so no build-time size
+# check is performed here (COMMAND_LINE_SIZE is an arch header
+# constant, not a Kconfig value).
+quiet_cmd_render_cmdline = BCONF2C $@
+ cmd_render_cmdline = \
+ $(objtree)/tools/bootconfig/bootconfig -C $< > $@
+
+targets += embedded_cmdline.bin
+$(obj)/embedded_cmdline.bin: $(obj)/default.bconf $(objtree)/tools/bootconfig/bootconfig FORCE
+ $(call if_changed,render_cmdline)
+
obj-$(CONFIG_RBTREE_TEST) += rbtree_test.o
obj-$(CONFIG_INTERVAL_TREE_TEST) += interval_tree_test.o
diff --git a/lib/embedded-cmdline.S b/lib/embedded-cmdline.S
new file mode 100644
index 000000000000..7e2e1d81af96
--- /dev/null
+++ b/lib/embedded-cmdline.S
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Embed the build-time-rendered bootconfig "kernel" subtree as a flat
+ * cmdline string. setup_arch() prepends this to boot_command_line on
+ * architectures that select ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG.
+ *
+ * Copyright (c) 2026 Meta Platforms, Inc. and affiliates
+ * Copyright (c) 2026 Breno Leitao <leitao@debian.org>
+ */
+ .section .init.rodata, "aw"
+ .global embedded_kernel_cmdline
+embedded_kernel_cmdline:
+ .incbin "lib/embedded_cmdline.bin"
+ .byte 0
+ .global embedded_kernel_cmdline_end
+embedded_kernel_cmdline_end:
diff --git a/tools/bootconfig/Makefile b/tools/bootconfig/Makefile
index 90eb47c9d8de..4e82fd9553cd 100644
--- a/tools/bootconfig/Makefile
+++ b/tools/bootconfig/Makefile
@@ -15,7 +15,7 @@ override CFLAGS += -Wall -g -I$(CURDIR)/include
ALL_TARGETS := bootconfig
ALL_PROGRAMS := $(patsubst %,$(OUTPUT)%,$(ALL_TARGETS))
-all: $(ALL_PROGRAMS) test
+all: $(ALL_PROGRAMS)
$(OUTPUT)bootconfig: main.c include/linux/bootconfig.h $(LIBSRC)
$(CC) $(filter %.c,$^) $(CFLAGS) $(LDFLAGS) -o $@
--
2.54.0
^ permalink raw reply related
* [PATCH 1/4] bootconfig: return 0 from xbc_snprint_cmdline() for a leaf root
From: Breno Leitao @ 2026-05-27 16:41 UTC (permalink / raw)
To: Masami Hiramatsu, Andrew Morton, Nathan Chancellor, paulmck,
Nicolas Schier
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, linux-kernel, linux-trace-kernel, linux-kbuild,
bpf, Breno Leitao, kernel-team
In-Reply-To: <20260527-bootconfig_using_tools-v1-0-b6906a86e7d5@debian.org>
Returning -EINVAL when @root has no descendant key nodes is a quirky
result for a renderer: "nothing to render" is not an error. The only
existing caller, xbc_make_cmdline(), papers over it with a `len <= 0`
check, so the misbehavior is harmless today. The new -C user in
tools/bootconfig added by the follow-up patches propagates the error
and turns an empty "kernel {}" subtree into a build failure.
Short-circuit the leaf-root case and return 0 so the rendered length
matches the rendered content.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
lib/bootconfig.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/lib/bootconfig.c b/lib/bootconfig.c
index f445b7703fdd..3a102c9122f7 100644
--- a/lib/bootconfig.c
+++ b/lib/bootconfig.c
@@ -431,6 +431,16 @@ int __init xbc_snprint_cmdline(char *buf, size_t size, struct xbc_node *root)
const char *val, *q;
int ret;
+ /*
+ * A leaf @root (e.g. an empty "kernel {}" subtree, or a key whose
+ * only child is a value node) has no descendant key/value pairs to
+ * render. The leaf-finding iterator below would otherwise return
+ * @root itself, which xbc_node_compose_key_after() rejects with
+ * -EINVAL.
+ */
+ if (root && xbc_node_is_leaf(root))
+ return 0;
+
xbc_node_for_each_key_value(root, knode, val) {
ret = xbc_node_compose_key_after(root, knode,
xbc_namebuf, XBC_KEYLEN_MAX);
--
2.54.0
^ permalink raw reply related
* [PATCH 0/4] bootconfig: embed kernel.* cmdline at build time
From: Breno Leitao @ 2026-05-27 16:41 UTC (permalink / raw)
To: Masami Hiramatsu, Andrew Morton, Nathan Chancellor, paulmck,
Nicolas Schier
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, linux-kernel, linux-trace-kernel, linux-kbuild,
bpf, Breno Leitao, kernel-team
The userspace pieces (xbc_snprint_cmdline() in lib/, tools/bootconfig -C)
already landed; this series wires the rendered cmdline into the kernel.
Motivation: today the embedded bootconfig is parsed at runtime, after
parse_early_param() has already run, so early_param() handlers can't
see embedded values. Folding the kernel.* subtree into the cmdline at
build time gives a CONFIG_CMDLINE-equivalent for embedded-bootconfig
users without forcing them to maintain two cmdline sources.
Behaviorally, the "kernel" subtree is rendered to a flat string at
build time and stashed in .init.rodata. setup_arch() prepends it to
boot_command_line before parse_early_param() runs. Overflow is a soft
error: the helper logs and leaves boot_command_line untouched rather
than panicking, so an oversized embedded bconf cannot brick a boot.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Breno Leitao (4):
bootconfig: return 0 from xbc_snprint_cmdline() for a leaf root
bootconfig: render embedded bootconfig as a kernel cmdline at build time
bootconfig: add xbc_prepend_embedded_cmdline() helper
x86/setup: prepend embedded bootconfig cmdline before parse_early_param
Makefile | 5 ++++
arch/x86/Kconfig | 1 +
arch/x86/kernel/setup.c | 3 +++
include/linux/bootconfig.h | 7 ++++++
init/Kconfig | 33 ++++++++++++++++++++++++++
init/main.c | 19 ++++++++++++---
lib/Makefile | 16 +++++++++++++
lib/bootconfig.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++
lib/embedded-cmdline.S | 16 +++++++++++++
tools/bootconfig/Makefile | 2 +-
10 files changed, 156 insertions(+), 4 deletions(-)
---
base-commit: e7e28506af98ce4e1059e5ec59334b335c00a246
change-id: 20260508-bootconfig_using_tools-cfa7aa9d6a5a
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [PATCH v2] scripts: Have make TAGS not include structure members'
From: Peter Zijlstra @ 2026-05-27 16:31 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux trace kernel, linux-kbuild, Andrew Morton,
Masahiro Yamada, Masatake YAMATO, Geert Uytterhoeven,
Michal Marek, Yang Bai, Stephen Boyd
In-Reply-To: <20260527162914.GH3102624@noisy.programming.kicks-ass.net>
On Wed, May 27, 2026 at 06:29:14PM +0200, Peter Zijlstra wrote:
> On Wed, May 27, 2026 at 12:11:44PM -0400, Steven Rostedt wrote:
> > From: Steven Rostedt <rostedt@goodmis.org>
> >
> > It is really annoying when I use emacs TAGS to search for something
> > like "dev_name" and have to go through 12 iterations before I find the
> > function "dev_name". I really do not care about structures that include
> > "dev_name" as one of its fields, and I'm sure pretty much all other
> > developers do not care either.
> >
> > There's a "remove_structs" variable used by the scripts/tags.sh, which
> > I'm guessing is suppose to remove these structures from the TAGS file,
> > but it must do a poor job at it, as I'm always hitting structures when
> > I want the actual declaration.
> >
> > Luckily, the etags program comes with an option "--no-members", which does
> > exactly what I want, and I'm sure all other kernel developers want too.
> >
> > Create a new "no_members" variable and assign it to "--no-members" for the
> > "TAGS" case and pass that to the etags program to remove structures.
> >
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> > ---
> > Changes since v1: https://lore.kernel.org/all/20131115093645.6dc03918@gandalf.local.home/
> >
> > - Use a no_members variable instead of hard coding the --no-members into
> > the etags call, as that can break some "tags" cases. (Michal Marek)
>
> Yeah, I often use member tags.
>
> The tags file have a 'kind' field, what you want is for emacs to order
> on kind and prefer 'f' over 'm'.
>
> The alternative is switching to use emacs-lsp, that way the editor knows
> the kind of symbol you want. If you're on a function call, it should
> only consider 'f' tags. Whereas if the cursor is on a member deref, it
> should only consider 'm'.
That said, setting up clangd on the kernel tree is rather more painful
that I'd like it to be :-(
^ permalink raw reply
* Re: [PATCH v2] scripts: Have make TAGS not include structure members
From: Peter Zijlstra @ 2026-05-27 16:29 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux trace kernel, linux-kbuild, Andrew Morton,
Masahiro Yamada, Masatake YAMATO, Geert Uytterhoeven,
Michal Marek, Yang Bai, Stephen Boyd
In-Reply-To: <20260527121144.08a1f676@fedora>
On Wed, May 27, 2026 at 12:11:44PM -0400, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> It is really annoying when I use emacs TAGS to search for something
> like "dev_name" and have to go through 12 iterations before I find the
> function "dev_name". I really do not care about structures that include
> "dev_name" as one of its fields, and I'm sure pretty much all other
> developers do not care either.
>
> There's a "remove_structs" variable used by the scripts/tags.sh, which
> I'm guessing is suppose to remove these structures from the TAGS file,
> but it must do a poor job at it, as I'm always hitting structures when
> I want the actual declaration.
>
> Luckily, the etags program comes with an option "--no-members", which does
> exactly what I want, and I'm sure all other kernel developers want too.
>
> Create a new "no_members" variable and assign it to "--no-members" for the
> "TAGS" case and pass that to the etags program to remove structures.
>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> Changes since v1: https://lore.kernel.org/all/20131115093645.6dc03918@gandalf.local.home/
>
> - Use a no_members variable instead of hard coding the --no-members into
> the etags call, as that can break some "tags" cases. (Michal Marek)
Yeah, I often use member tags.
The tags file have a 'kind' field, what you want is for emacs to order
on kind and prefer 'f' over 'm'.
The alternative is switching to use emacs-lsp, that way the editor knows
the kind of symbol you want. If you're on a function call, it should
only consider 'f' tags. Whereas if the cursor is on a member deref, it
should only consider 'm'.
^ permalink raw reply
* Re: [PATCH v3 2/2] serial: qcom-geni: Add tracepoints for Qualcomm GENI serial driver
From: Praveen Talari @ 2026-05-27 16:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Jiri Slaby,
Konrad Dybcio, linux-kernel, linux-trace-kernel, linux-arm-msm,
linux-serial, Mukesh Kumar Savaliya, Aniket Randive,
chandana.chiluveru, jyothi.seerapu
In-Reply-To: <2026052738-unexpired-diligence-10f8@gregkh>
Hi
On 27-05-2026 13:47, Greg Kroah-Hartman wrote:
> On Tue, May 26, 2026 at 10:36:18AM +0530, Praveen Talari wrote:
>> Hi
>>
>> On 22-05-2026 15:17, Greg Kroah-Hartman wrote:
>>> On Mon, May 18, 2026 at 11:26:56PM +0530, Praveen Talari wrote:
>>>> Add tracing to the Qualcomm GENI serial driver to improve runtime
>>>> observability.
>>>>
>>>> Trace hooks are added at key points including termios and clock
>>>> configuration, manual control get/set, interrupt handling, and data
>>>> TX/RX paths.
>>>>
>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
>>>> ---
>>>> v2->v3:
>>>> - Updated commit text(removed example as it was available on cover
>>>> letter).
>>>> ---
>>>> drivers/tty/serial/qcom_geni_serial.c | 27 +++++++++++++++++++++++----
>>>> 1 file changed, 23 insertions(+), 4 deletions(-)
>>> This patch did not apply to my tree :(
>> Do you mean these patches are not applied cleanly?
> Yes.
>
>> If yes, i will push on linux-next tip.
> You mean rebase, right?
Yes, i have already posted V4.
https://lore.kernel.org/all/20260526-add-tracepoints-for-qcom-geni-serial-v4-0-e94fbaec0232@oss.qualcomm.com/
Thanks,
Praveen Talari
>
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH v2] scripts: Have make TAGS not include structure members
From: Steven Rostedt @ 2026-05-27 16:11 UTC (permalink / raw)
To: LKML, Linux trace kernel, linux-kbuild
Cc: Andrew Morton, Masahiro Yamada, Masatake YAMATO, Peter Zijlstra,
Geert Uytterhoeven, Michal Marek, Yang Bai, Stephen Boyd
From: Steven Rostedt <rostedt@goodmis.org>
It is really annoying when I use emacs TAGS to search for something
like "dev_name" and have to go through 12 iterations before I find the
function "dev_name". I really do not care about structures that include
"dev_name" as one of its fields, and I'm sure pretty much all other
developers do not care either.
There's a "remove_structs" variable used by the scripts/tags.sh, which
I'm guessing is suppose to remove these structures from the TAGS file,
but it must do a poor job at it, as I'm always hitting structures when
I want the actual declaration.
Luckily, the etags program comes with an option "--no-members", which does
exactly what I want, and I'm sure all other kernel developers want too.
Create a new "no_members" variable and assign it to "--no-members" for the
"TAGS" case and pass that to the etags program to remove structures.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
Changes since v1: https://lore.kernel.org/all/20131115093645.6dc03918@gandalf.local.home/
- Use a no_members variable instead of hard coding the --no-members into
the etags call, as that can break some "tags" cases. (Michal Marek)
- Rebase to the current decade. Yes, v1 is from 2013. I've been carrying
this patch in my personal repos as a quilt entry where I would just push
it when doing a "make TAGS". I also have the conversation still in my
INBOX to remind me to send a v2. Talk about procrastination! It only
took me 13 years to send the v2 :-p
I'm still keeping the same Cc's. I wonder how many of them will be
broken. :-/
scripts/tags.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/tags.sh b/scripts/tags.sh
index 243373683f98..018588014eed 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -305,7 +305,7 @@ exuberant()
emacs()
{
setup_regex emacs asm c
- all_target_sources | xargs $1 -a "${regex[@]}"
+ all_target_sources | xargs $1 -a $no_members "${regex[@]}"
setup_regex emacs kconfig
all_kconfigs | xargs $1 -a "${regex[@]}"
@@ -334,6 +334,7 @@ if [ "${ARCH}" = "um" ]; then
fi
remove_structs=
+no_members=
case "$1" in
"cscope")
docscope
@@ -353,6 +354,7 @@ case "$1" in
rm -f TAGS
xtags etags
remove_structs=y
+ no_members=--no-members
;;
esac
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3] perf/ftrace: Fix WARNING in __unregister_ftrace_function
From: Rik van Riel @ 2026-05-27 15:43 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-kernel, kernel-team,
linux-trace-kernel
In-Reply-To: <20260527113732.664d26db@fedora>
On Wed, 2026-05-27 at 11:37 -0400, Steven Rostedt wrote:
> On Wed, 27 May 2026 11:13:01 -0400
> Rik van Riel <riel@surriel.com> wrote:
>
> > perf_ftrace_function_unregister() unconditionally calls
> > unregister_ftrace_function() without checking whether the
> > ftrace_ops
> > was ever successfully registered. This triggers a WARN_ON in
> > __unregister_ftrace_function() when the ops doesn't have
> > FTRACE_OPS_FL_ENABLED set.
> >
> > This can happen during perf_event_alloc() error cleanup when
> > perf_trace_destroy() is called via __free_event() on an event whose
> > ftrace_ops registration failed or was already torn down by
> > perf_try_init_event()'s err_destroy path.
> >
> > The call path is:
> > perf_event_alloc() error cleanup
> > -> __free_event()
> > -> event->destroy() [tp_perf_event_destroy]
> > -> perf_trace_destroy()
> > -> perf_trace_event_close()
> > -> TRACE_REG_PERF_CLOSE
> > -> perf_ftrace_function_unregister()
> > -> unregister_ftrace_function()
> > -> __unregister_ftrace_function()
> > -> WARN_ON(!(ops->flags &
> > FTRACE_OPS_FL_ENABLED))
> >
> > Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to
> > unregister. If the ops is not enabled, just free the filter and
> > return success.
> >
> > Signed-off-by: Rik van Riel <riel@surriel.com>
>
> Thanks Rik. Is this urgent where it should have a Fixes tag and Cc
> stable as well as be sent to Linus during the -rc release, or can it
> wait for the next merge window?
>
I don't think this patch has any particular urgency.
It can go in using whatever flow is most convenient.
--
All Rights Reversed.
^ permalink raw reply
* Re: [PATCH 07/13] rv: Simply hybrid automata monitors's clock variables
From: Nam Cao @ 2026-05-27 15:41 UTC (permalink / raw)
To: Gabriele Monaco
Cc: Steven Rostedt, Wander Lairson Costa, linux-trace-kernel,
linux-kernel
In-Reply-To: <054cfff25288a98a7d7922de149be91fcbc79bc0.camel@redhat.com>
Gabriele Monaco <gmonaco@redhat.com> writes:
> I'd prefer if this was consistent with the above as in (now - env <=
> expire) or (env >= now - env), whichever you prefer but let's keep it
> equivalent.
> Or do you have a reason to rearrange it here?
No reason. Let's keep it consistent.
Thanks for the comments.
Nam
^ permalink raw reply
* Re: [PATCH v3] perf/ftrace: Fix WARNING in __unregister_ftrace_function
From: Steven Rostedt @ 2026-05-27 15:37 UTC (permalink / raw)
To: Rik van Riel
Cc: Masami Hiramatsu, Mathieu Desnoyers, linux-kernel, kernel-team,
linux-trace-kernel
In-Reply-To: <20260527111301.2d0d8256@fangorn>
On Wed, 27 May 2026 11:13:01 -0400
Rik van Riel <riel@surriel.com> wrote:
> perf_ftrace_function_unregister() unconditionally calls
> unregister_ftrace_function() without checking whether the ftrace_ops
> was ever successfully registered. This triggers a WARN_ON in
> __unregister_ftrace_function() when the ops doesn't have
> FTRACE_OPS_FL_ENABLED set.
>
> This can happen during perf_event_alloc() error cleanup when
> perf_trace_destroy() is called via __free_event() on an event whose
> ftrace_ops registration failed or was already torn down by
> perf_try_init_event()'s err_destroy path.
>
> The call path is:
> perf_event_alloc() error cleanup
> -> __free_event()
> -> event->destroy() [tp_perf_event_destroy]
> -> perf_trace_destroy()
> -> perf_trace_event_close()
> -> TRACE_REG_PERF_CLOSE
> -> perf_ftrace_function_unregister()
> -> unregister_ftrace_function()
> -> __unregister_ftrace_function()
> -> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED))
>
> Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to
> unregister. If the ops is not enabled, just free the filter and
> return success.
>
> Signed-off-by: Rik van Riel <riel@surriel.com>
Thanks Rik. Is this urgent where it should have a Fixes tag and Cc
stable as well as be sent to Linus during the -rc release, or can it
wait for the next merge window?
-- Steve
^ permalink raw reply
* Re: [PATCH v6 05/43] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Ackerley Tng @ 2026-05-27 15:35 UTC (permalink / raw)
To: Sean Christopherson, Fuad Tabba
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Baoquan He, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka, kvm,
linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <CAEvNRgEZ9vCKkoMC11tVrueAonGWH2x6OeaYYxXGEj2gwHUaKw@mail.gmail.com>
Ackerley Tng <ackerleytng@google.com> writes:
>
> [...snip...]
>
>>
>> Hmm, I wonder if we can figure out a way to consolidate some documentation,
>> because this is _exactly_ the same pattern that x86's host_pfn_mapping_level()
>> deals with (see its big comment below).
>>
>
> This would be great, are you thinking an actual comment or something in
> Documentation/?
>
> Perhaps we could iterate on this a little with me providing the newbie
> perspective. Do you want me to take a stab at writing something up?
>
Please see https://lore.kernel.org/all/20260527-kvm-locking-docs-v1-0-4fe8b602ff47@google.com/T/!
>>
>> [...snip...]
>>
^ 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