* [GIT PULL] tracing: Updates for v6.17
@ 2025-07-31 14:17 Steven Rostedt
2025-07-31 17:29 ` Alexei Starovoitov
2025-08-01 17:35 ` pr-tracker-bot
0 siblings, 2 replies; 5+ messages in thread
From: Steven Rostedt @ 2025-07-31 14:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: LKML, Masami Hiramatsu, Mathieu Desnoyers, Andrew Morton,
Mark Rutland, Arnd Bergmann, Nam Cao, Ricardo Neri, Yury Norov
Linus,
tracing changes for 6.17
- Deprecate auto-mounting tracefs to /sys/kernel/debug/tracing
When tracefs was first introduced back in 2014, the directory
/sys/kernel/tracing was added and is the designated location to mount
tracefs. To keep backward compatibility, tracefs was auto-mounted in
/sys/kernel/debug/tracing as well.
All distros now mount tracefs on /sys/kernel/tracing. Having it seen in two
different locations has lead to various issues and inconsistencies.
The VFS folks have to also maintain debugfs_create_automount() for this
single user.
It's been over 10 years. Tooling and scripts should start replacing the
debugfs location with the tracefs one. The reason tracefs was created in the
first place was to allow access to the tracing facilities without the need
to configure debugfs into the kernel. Using tracefs should now be more
robust.
A new config is created: CONFIG_TRACEFS_AUTOMOUNT_DEPRECATED
which is default y, so that the kernel is still built with the automount.
This config allows those that want to remove the automount from debugfs to
do so.
When tracefs is accessed from /sys/kernel/debug/tracing, the following
printk is triggerd:
pr_warn("NOTICE: Automounting of tracing to debugfs is deprecated and will be removed in 2030\n");
This gives users another 5 years to fix their scripts.
- Use queue_rcu_work() instead of call_rcu() for freeing event filters
The number of filters to be free can be many depending on the number of
events within an event system. Freeing them from softirq context can
potentially cause undesired latency. Use the RCU workqueue to free them
instead.
- Remove pointless memory barriers in latency code
Memory barriers were added to some of the latency code a long time ago with
the idea of "making them visible", but that's not what memory barriers are
for. They are to synchronize access between different variables. There was
no synchronization here making them pointless.
- Remove "__attribute__()" from the type field of event format
When LLVM is used to compile the kernel with CONFIG_DEBUG_INFO_BTF=y and
PAHOLE_HAS_BTF_TAG=y, some of the format fields get expanded with the
following:
field:const char * filename; offset:24; size:8; signed:0;
Turns into:
field:const char __attribute__((btf_type_tag("user"))) * filename; offset:24; size:8; signed:0;
This confuses parsers. Add code to strip these tags from the strings.
- Add eprobe config option CONFIG_EPROBE_EVENTS
Eprobes were added back in 5.15 but were only enabled when another probe was
enabled (kprobe, fprobe, uprobe, etc). The eprobes had no config option
of their own. Add one as they should be a separate entity.
It's default y to keep with the old kernels but still has dependencies on
TRACING and HAVE_REGS_AND_STACK_ACCESS_API.
- Add eprobe documentation
When eprobes were added back in 5.15 no documentation was added to describe
them. This needs to be rectified.
- Replace open coded cpumask_next_wrap() in move_to_next_cpu()
- Have preemptirq_delay_run() use off-stack CPU mask
- Remove obsolete comment about pelt_cfs event
DECLARE_TRACE() appends "_tp" to trace events now, but the comment above
pelt_cfs still mentioned appending it manually.
- Remove EVENT_FILE_FL_SOFT_MODE flag
The SOFT_MODE flag was required when the soft enabling and disabling of
trace events was first introduced. But there was a bug with this approach
as it only worked for a single instance. When multiple users required soft
disabling and disabling the code was changed to have a ref count. The
SOFT_MODE flag is now set iff the ref count is non zero. This is redundant
and just reading the ref count is good enough.
- Fix typo in comment
Please pull the latest trace-v6.17 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
trace-v6.17
Tag SHA1: 24e6f06fdcad116feaabae15bcff715b2ba16386
Head SHA1: 623526ba8984cafdffa0eba7ee424f2e40c8a219
Arnd Bergmann (1):
kernel: trace: preemptirq_delay_test: use offstack cpu mask
Masami Hiramatsu (Google) (1):
tracing: Remove "__attribute__()" from the type field of event format
Nam Cao (1):
tracing: Remove pointless memory barriers
Ricardo Neri (1):
tracing/sched: Remove obsolete comment on suffixes
Steven Rostedt (6):
tracing: Use queue_rcu_work() to free filters
tracing: Remove EVENT_FILE_FL_SOFT_MODE flag
tracing: Fix comment in trace_module_remove_events()
tracing: Deprecate auto-mounting tracefs in debugfs
tracing: Have eprobes have their own config option
Documentation: tracing: Add documentation about eprobes
Yury Norov (1):
tracing: Replace opencoded cpumask_next_wrap() in move_to_next_cpu()
----
.../ABI/obsolete/automount-tracefs-debugfs | 20 ++
Documentation/trace/eprobetrace.rst | 269 +++++++++++++++++++++
Documentation/trace/index.rst | 1 +
include/linux/trace_events.h | 3 -
include/trace/events/sched.h | 2 -
kernel/trace/Kconfig | 27 +++
kernel/trace/Makefile | 2 +-
kernel/trace/preemptirq_delay_test.c | 13 +-
kernel/trace/rv/rv.c | 6 -
kernel/trace/trace.c | 49 ++--
kernel/trace/trace.h | 4 +-
kernel/trace/trace_events.c | 154 +++++++++---
kernel/trace/trace_events_filter.c | 28 ++-
kernel/trace/trace_hwlat.c | 5 +-
14 files changed, 498 insertions(+), 85 deletions(-)
create mode 100644 Documentation/ABI/obsolete/automount-tracefs-debugfs
create mode 100644 Documentation/trace/eprobetrace.rst
---------------------------
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PULL] tracing: Updates for v6.17
2025-07-31 14:17 [GIT PULL] tracing: Updates for v6.17 Steven Rostedt
@ 2025-07-31 17:29 ` Alexei Starovoitov
2025-07-31 20:38 ` Steven Rostedt
2025-08-01 17:35 ` pr-tracker-bot
1 sibling, 1 reply; 5+ messages in thread
From: Alexei Starovoitov @ 2025-07-31 17:29 UTC (permalink / raw)
To: Steven Rostedt
Cc: Linus Torvalds, LKML, Masami Hiramatsu, Mathieu Desnoyers,
Andrew Morton, Mark Rutland, Arnd Bergmann, Nam Cao,
Ricardo Neri, Yury Norov
On Thu, Jul 31, 2025 at 10:17:17AM -0400, Steven Rostedt wrote:
>
> When tracefs is accessed from /sys/kernel/debug/tracing, the following
> printk is triggerd:
>
> pr_warn("NOTICE: Automounting of tracing to debugfs is deprecated and will be removed in 2030\n");
>
> This gives users another 5 years to fix their scripts.
Not objecting to PR, but I don't get the point of the warn.
In libbpf we have this logic:
#define DEBUGFS "/sys/kernel/debug/tracing"
#define TRACEFS "/sys/kernel/tracing"
static bool use_debugfs(void)
{
static int has_debugfs = -1;
if (has_debugfs < 0)
has_debugfs = faccessat(AT_FDCWD, DEBUGFS, F_OK, AT_EACCESS) == 0;
return has_debugfs == 1;
}
static const char *tracefs_path(void)
{
return use_debugfs() ? DEBUGFS : TRACEFS;
}
So it will trigger the warn just because libbpf tries to find tracefs
in debugfs first ?
We can switch the order, no big deal.
What about other tools ?
bpftrace has similar logic:
#define DEBUGFS_TRACEFS "/sys/kernel/debug/tracing"
#define TRACEFS "/sys/kernel/tracing"
std::string path()
{
static bool use_debugfs = access(DEBUGFS_TRACEFS, F_OK) == 0;
return use_debugfs ? DEBUGFS_TRACEFS : TRACEFS;
}
In 5 years all these tools can switch the order, no problem,
but I don't get the point. Most, it not all tools, have similar tracefs
detection logic. Just remove automount right now without warn,
since the warn is only noise and churn to tools to swap the order
of detection ?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PULL] tracing: Updates for v6.17
2025-07-31 17:29 ` Alexei Starovoitov
@ 2025-07-31 20:38 ` Steven Rostedt
2025-07-31 20:40 ` Steven Rostedt
0 siblings, 1 reply; 5+ messages in thread
From: Steven Rostedt @ 2025-07-31 20:38 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Linus Torvalds, LKML, Masami Hiramatsu, Mathieu Desnoyers,
Andrew Morton, Mark Rutland, Arnd Bergmann, Nam Cao,
Ricardo Neri, Yury Norov
On Thu, 31 Jul 2025 10:29:49 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> In 5 years all these tools can switch the order, no problem,
> but I don't get the point. Most, it not all tools, have similar tracefs
> detection logic. Just remove automount right now without warn,
> since the warn is only noise and churn to tools to swap the order
> of detection ?
The issue is that if we just remove it now, it *will* break a lot of
scripts. I know many people that have scripts hardcoded with just
/sys/kernel/debug/tracing in use (Peter Zijlstra for one).
tracefs has been in the kernel for over 5 years and there's still kernel
developers that are unaware that it has its own directory! After posting
this patch to the public, a had a couple of people tell me privately that
they didn't know about /sys/kernel/tracing. That's why I want the warning.
I'd suggest to switch the logic, or do what libtracefs does and parse the
/proc/mounts directory:
https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/tree/src/tracefs-utils.c#n89
It only uses debugfs if tracefs isn't found.
Even my own scripts have been doing this for years: (from the ftrace kselftests):
TRACING_DIR=`grep tracefs /proc/mounts | cut -f2 -d' ' | head -1`
if [ -z "$TRACING_DIR" ]; then
DEBUGFS_DIR=`grep debugfs /proc/mounts | cut -f2 -d' ' | head -1`
if [ -z "$DEBUGFS_DIR" ]; then
# If tracefs exists, then so does /sys/kernel/tracing
if [ -d "/sys/kernel/tracing" ]; then
mount -t tracefs nodev /sys/kernel/tracing ||
errexit "Failed to mount /sys/kernel/tracing"
TRACING_DIR="/sys/kernel/tracing"
UMOUNT_DIR=${TRACING_DIR}
# If debugfs exists, then so does /sys/kernel/debug
elif [ -d "/sys/kernel/debug" ]; then
mount -t debugfs nodev /sys/kernel/debug ||
errexit "Failed to mount /sys/kernel/debug"
TRACING_DIR="/sys/kernel/debug/tracing"
UMOUNT_DIR=${TRACING_DIR}
else
err_ret=$err_skip
errexit "debugfs and tracefs are not configured in this kernel"
fi
else
TRACING_DIR="$DEBUGFS_DIR/tracing"
fi
fi
-- Steve
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PULL] tracing: Updates for v6.17
2025-07-31 20:38 ` Steven Rostedt
@ 2025-07-31 20:40 ` Steven Rostedt
0 siblings, 0 replies; 5+ messages in thread
From: Steven Rostedt @ 2025-07-31 20:40 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Linus Torvalds, LKML, Masami Hiramatsu, Mathieu Desnoyers,
Andrew Morton, Mark Rutland, Arnd Bergmann, Nam Cao,
Ricardo Neri, Yury Norov
On Thu, 31 Jul 2025 16:38:31 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> tracefs has been in the kernel for over 5 years and there's still kernel
I meant to say 10 years, but the "5" from removing it completely was still
in my head :-p
-- Steve
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [GIT PULL] tracing: Updates for v6.17
2025-07-31 14:17 [GIT PULL] tracing: Updates for v6.17 Steven Rostedt
2025-07-31 17:29 ` Alexei Starovoitov
@ 2025-08-01 17:35 ` pr-tracker-bot
1 sibling, 0 replies; 5+ messages in thread
From: pr-tracker-bot @ 2025-08-01 17:35 UTC (permalink / raw)
To: Steven Rostedt
Cc: Linus Torvalds, LKML, Masami Hiramatsu, Mathieu Desnoyers,
Andrew Morton, Mark Rutland, Arnd Bergmann, Nam Cao,
Ricardo Neri, Yury Norov
The pull request you sent on Thu, 31 Jul 2025 10:17:17 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git trace-v6.17
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d6f38c12396397e48092ad9e8a4d7be4de51b942
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-08-01 17:35 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-07-31 14:17 [GIT PULL] tracing: Updates for v6.17 Steven Rostedt
2025-07-31 17:29 ` Alexei Starovoitov
2025-07-31 20:38 ` Steven Rostedt
2025-07-31 20:40 ` Steven Rostedt
2025-08-01 17:35 ` pr-tracker-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®