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]

Message-ID: <CAADnVQ+F3Z70mu3-QyyNFyJ2qCkDXnMJCW-o+fcnZo=LWj5d9g@mail.gmail.com>
Date:   Mon, 30 Jan 2023 12:03:52 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
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, Jan 30, 2023 at 11:59 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Mon, 30 Jan 2023 11:52:03 -0800
> Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
>
> > On Mon, Jan 30, 2023 at 10:19 AM Ross Zwisler <zwisler@...omium.org> wrote:
> > >
> > > The canonical location for the tracefs filesystem is at /sys/kernel/tracing.
> > >
> > > But, from Documentation/trace/ftrace.rst:
> > >
> > >   Before 4.1, all ftrace tracing control files were within the debugfs
> > >   file system, which is typically located at /sys/kernel/debug/tracing.
> > >   For backward compatibility, when mounting the debugfs file system,
> > >   the tracefs file system will be automatically mounted at:
> > >
> > >   /sys/kernel/debug/tracing
> > >
> > > Many tests in the bpf selftest code still refer to this older debugfs
> > > path, so let's update them to avoid confusion.
> >
> > I wish that was the case, but in reality there are still systems
> > out there where tracefs is only mounted in that old location.
> > For example in one my VMs:
> >
> > $ cat /proc/mounts |grep tracefs
> > tracefs /sys/kernel/debug/tracing tracefs rw,relatime 0 0
> > $ ls /sys/kernel/tracing/
> > $ uname -r
> > 6.2.0-rc5-01030-gc1a3daf7363b
> >
> > So this change will break the tests. We cannot do it.
>
> Could we add a way to try to mount it?
>
> If anything, the tests should not have the path hard coded. It should then
> look to see if it is mounted and use the path that is found. Otherwise it
> should try mounting it at the correct location.
>
> Feel free to take the code from libtracefs (and modify it):
>
> https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/tree/src/tracefs-utils.c#n89
>
> It will make the test code much more robust.

The point is not about tests. The point is that this change might break
some users that are working today with /sys/kernel/debug/tracing.
It also might be mounted differently.
For example from another system:
cat /proc/mounts|grep trace
tracefs /sys/kernel/tracing tracefs rw,nosuid,nodev,noexec,relatime 0 0
tracefs /sys/kernel/debug/tracing tracefs rw,relatime 0 0

So I suggest leaving the code as-is.