linux-kernel - Re: [GIT PULL] tracing: Updates for v6.17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250731163831.3149a14a@gandalf.local.home>
Date: Thu, 31 Jul 2025 16:38:31 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, LKML
 <linux-kernel@...r.kernel.org>, Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Andrew Morton
 <akpm@...ux-foundation.org>, Mark Rutland <mark.rutland@....com>, Arnd
 Bergmann <arnd@...db.de>, Nam Cao <namcao@...utronix.de>, Ricardo Neri
 <ricardo.neri-calderon@...ux.intel.com>, Yury Norov <yury.norov@...il.com>
Subject: Re: [GIT PULL] tracing: Updates for v6.17

On Thu, 31 Jul 2025 10:29:49 -0700
Alexei Starovoitov <alexei.starovoitov@...il.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