bpftool uses wrong order of tracefs search

bpftool uses wrong order of tracefs search

[Alexei Starovoitov]

Hi Quentin,

since last merge window bpftool triggers a warn:
$ bpftool prog tracelog
[   72.942082] NOTICE: Automounting of tracing to debugfs is
deprecated and will be removed in 2030


I suspect it happens because get_tracefs_pipe()
accesses debug/tracing first which causes automnount
and triggers this warning.

Pls take a look.

Re: bpftool uses wrong order of tracefs search

[Quentin Monnet]

2025-09-11 10:27 UTC-0700 ~ Alexei Starovoitov
<alexei.starovoitov@gmail.com>
> Hi Quentin,
> 
> since last merge window bpftool triggers a warn:
> $ bpftool prog tracelog
> [   72.942082] NOTICE: Automounting of tracing to debugfs is
> deprecated and will be removed in 2030
> 
> 
> I suspect it happens because get_tracefs_pipe()
> accesses debug/tracing first which causes automnount
> and triggers this warning.
> 
> Pls take a look.


Hi Alexei, sure, I'll look into it.

I haven't tested yet, but the check on /sys/kernel/debug/tracing is
likely to be the cause indeed. If that's the case, would that be OK to
move it to the end of the "known_mnts" list in the function? Or do you
prefer to avoid the warning completely, even at the cost of missing the
tracefs on older systems?

Quentin

Re: bpftool uses wrong order of tracefs search

[Alexei Starovoitov]

On Thu, Sep 11, 2025 at 2:03 PM Quentin Monnet <qmo@kernel.org> wrote:
>
> 2025-09-11 10:27 UTC-0700 ~ Alexei Starovoitov
> <alexei.starovoitov@gmail.com>
> > Hi Quentin,
> >
> > since last merge window bpftool triggers a warn:
> > $ bpftool prog tracelog
> > [   72.942082] NOTICE: Automounting of tracing to debugfs is
> > deprecated and will be removed in 2030
> >
> >
> > I suspect it happens because get_tracefs_pipe()
> > accesses debug/tracing first which causes automnount
> > and triggers this warning.
> >
> > Pls take a look.
>
>
> Hi Alexei, sure, I'll look into it.
>
> I haven't tested yet, but the check on /sys/kernel/debug/tracing is
> likely to be the cause indeed. If that's the case, would that be OK to
> move it to the end of the "known_mnts" list in the function? Or do you
> prefer to avoid the warning completely, even at the cost of missing the
> tracefs on older systems?

Older kernels won't have this warn.
Also I don't know what these are:
                "/tracing",
                "/trace",
I think the fix would be to do:
"/sys/kernel/tracing",
"/sys/kernel/debug/tracing",

Re: bpftool uses wrong order of tracefs search

[Steven Rostedt]

On Thu, 11 Sep 2025 14:32:50 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> Older kernels won't have this warn.
> Also I don't know what these are:
>                 "/tracing",
>                 "/trace",

It was common for people to hardcode the tracing and debug directories to
short names. I use to do it, and I believe Arnaldo did it as well.

> I think the fix would be to do:
> "/sys/kernel/tracing",
> "/sys/kernel/debug/tracing",

Note, the libtracefs uses /proc/mounts to find the directory. Feel free to
copy it and tweak it for your needs:

  https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/tree/src/tracefs-utils.c#n89

It has some legacy code to allow finding the debugfs directory first, which
shouldn't be needed anymore.

-- Steve

Re: bpftool uses wrong order of tracefs search

[Alexei Starovoitov]

On Thu, Sep 11, 2025 at 2:38 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 11 Sep 2025 14:32:50 -0700
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > Older kernels won't have this warn.
> > Also I don't know what these are:
> >                 "/tracing",
> >                 "/trace",
>
> It was common for people to hardcode the tracing and debug directories to
> short names. I use to do it, and I believe Arnaldo did it as well.
>
> > I think the fix would be to do:
> > "/sys/kernel/tracing",
> > "/sys/kernel/debug/tracing",
>
> Note, the libtracefs uses /proc/mounts to find the directory. Feel free to
> copy it and tweak it for your needs:
>
>   https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/tree/src/tracefs-utils.c#n89

get_tracefs_pipe() searches /proc on 2nd step,
and I would keep it in that order, since /proc parsing isn't fast.