mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [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®