user/sven/linux.git/kernel/trace, branch next/HEAD

Merge branch 'next' of https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git

2026-04-09T13:55:26Z

# Conflicts: # include/uapi/linux/kvm.h

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git

2026-04-09T13:43:01Z

Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

2026-04-09T13:29:03Z

Merge branch 'timers/urgent' into timers/core

2026-04-08T15:11:17Z

to resolve the conflict with the urgent clockevents fixes.

bpf: Prefer vmlinux symbols over module symbols for unqualified kprobes

2026-04-07T23:27:52Z

When an unqualified kprobe target exists in both vmlinux and a loaded module, number_of_same_symbols() returns a count greater than 1, causing kprobe attachment to fail with -EADDRNOTAVAIL even though the vmlinux symbol is unambiguous. When no module qualifier is given and the symbol is found in vmlinux, return the vmlinux-only count without scanning loaded modules. This preserves the existing behavior for all other cases: - Symbol only in a module: vmlinux count is 0, falls through to module scan as before. - Symbol qualified with MOD:SYM: mod != NULL, unchanged path. - Symbol ambiguous within vmlinux itself: count > 1 is returned as-is. Fixes: 926fe783c8a6 ("tracing/kprobes: Fix symbol counting logic by looking at modules as well") Fixes: 9d8616034f16 ("tracing/kprobes: Add symbol counting check when module loads") Suggested-by: Ihor Solodrai Acked-by: Jiri Olsa Acked-by: Ihor Solodrai Signed-off-by: Andrey Grodzovsky Link: https://lore.kernel.org/r/20260407203912.1787502-2-andrey.grodzovsky@crowdstrike.com Signed-off-by: Alexei Starovoitov

Merge trace/for-next

2026-04-04T16:38:07Z

Merge ring-buffer/for-next

2026-04-04T16:38:06Z

Merge probes/for-next

2026-04-04T16:38:05Z

Merge ftrace/for-next

2026-04-04T16:38:05Z

tracing: Allow backup to save persistent ring buffer before it starts

2026-04-02T17:29:08Z

When the persistent ring buffer was first introduced, it did not make sense to start tracing for it on the kernel command line. That's because if there was a crash, the start of events would invalidate the events from the previous boot that had the crash. But now that there's a "backup" instance that can take a snapshot of the persistent ring buffer when boot starts, it is possible to have the persistent ring buffer start events at boot up and not lose the old events. Update the code where the boot events start after all boot time instances are created. This will allow the backup instance to copy the persistent ring buffer from the previous boot, and allow the persistent ring buffer to start tracing new events for the current boot. reserve_mem=100M:12M:trace trace_instance=boot_mapped^@trace,sched trace_instance=backup=boot_mapped The above will create a boot_mapped persistent ring buffer and enabled the scheduler events. If there's a crash, a "backup" instance will be created holding the events of the persistent ring buffer from the previous boot, while the persistent ring buffer will once again start tracing scheduler events of the current boot. Now the user doesn't have to remember to start the persistent ring buffer. It will always have the events started at each boot. Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: John Stultz Link: https://patch.msgid.link/20260331163924.6ccb3896@gandalf.local.home Signed-off-by: Steven Rostedt (Google)