linux-kernel - Re: [PATCH 3/9] selftests/bpf: use canonical ftrace path

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]

Date:   Tue, 31 Jan 2023 14:50:48 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Ross Zwisler <zwisler@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ross Zwisler <zwisler@...gle.com>,
        Andrii Nakryiko <andrii@...nel.org>,
        linux-trace-kernel@...r.kernel.org,
        Mykola Lysenko <mykolal@...com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
        Shuah Khan <shuah@...nel.org>, bpf <bpf@...r.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH 3/9] selftests/bpf: use canonical ftrace path

On Mon, 30 Jan 2023 16:53:15 -0800
Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:

> I don't think /sys/kernel/debug/tracing can ever be deprecated.
> There are plenty of user space applications (not bpf related at all) that
> expect it to be in that location.
> 
> Quick search shows:
> 
> android profiler:
> https://android.googlesource.com/platform/external/perfetto/+/refs/heads/master/src/tools/dump_ftrace_stats/main.cc#60
> 
> java profiler:
> https://github.com/jvm-profiling-tools/async-profiler/blob/master/src/perfEvents_linux.cpp#L85

These can easily be changed. We have deprecated stuff in the past, by
making sure all the affected code is updated properly.

One way is to start adding printks when used. Then update to WARN() to get
people to complain. Yes, the burden is on us (me and others) to go out and
fix the issues. But it is possible to do, as I've done it before.

> 
> > If anything, leaving hardcoded calls like that forces the user to mount
> > debugfs when they may not want to. The entire point of tracefs was to allow
> > users to have access to the trace events without having to expose debugfs
> > and all the crud it brings with it. This was requested several times before
> > it was added.  
> 
> All makes sense.
> 
> > What is your technical reason for not modifying the code to look for
> > tracefs in /sys/kernel/tracing and if it's not there try
> > /sys/kernel/debug/tracing, and if both are not found, try mounting it.  
> 
> libbpf already has code to probe both locations.
> The point that full deprecation of /sys/kernel/debug/tracing is not possible,
> hence no point doing the diff:
> 48 files changed, 96 insertions(+), 95 deletions(-)
> It doesn't move the needle. Just a code churn.

As code in the Linux kernel is used as examples for future work, it should
not be using an interface that is obsolete. That's enough rational for code
churn. This "we can never deprecated so we won't even try" BS is not an
answer.

-- Steve