Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220826230639.1249436-1-yosryahmed@google.com>
 <CA+khW7iN6hyyBBR+4ey+9pNmEyKPZS82-C9kZ2NRXKMEOXHrng@mail.gmail.com>
 <CAJD7tkYKYv+SKhCJs2281==55sALTX_DXifaWPv1w5=xrJjqQA@mail.gmail.com>
 <CAJD7tkZg2jzDDR6vn5=-TS93Tm3P-YEQ+06KDsjg=Mzkt5LqsA@mail.gmail.com>
 <CA+khW7g-jeiXMM-K+KK7L3tzG0catFSM+x5vHKMs=PF=s+=Pag@mail.gmail.com> <CAJD7tkZ77JDt62CMw2AmpvTJ5fpVs0mkPdVqMJm8X8zCBq=LhA@mail.gmail.com>
In-Reply-To: <CAJD7tkZ77JDt62CMw2AmpvTJ5fpVs0mkPdVqMJm8X8zCBq=LhA@mail.gmail.com>
From:   Yosry Ahmed <yosryahmed@google.com>
Date:   Tue, 6 Sep 2022 14:35:15 -0700
Message-ID: <CAJD7tkZz52GkTr+TuZnArEOsyxxMPnE5A1AKZfY-gjx0tUW6dQ@mail.gmail.com>
Subject: Re: [PATCH] selftests/bpf: simplify cgroup_hierarchical_stats selftest
To:     Hao Luo <haoluo@google.com>
Cc:     Andrii Nakryiko <andrii@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Martin KaFai Lau <martin.lau@linux.dev>,
        Mykola Lysenko <mykolal@fb.com>, Song Liu <song@kernel.org>,
        Yonghong Song <yhs@fb.com>,
        John Fastabend <john.fastabend@gmail.com>,
        KP Singh <kpsingh@kernel.org>,
        Stanislav Fomichev <sdf@google.com>,
        Jiri Olsa <jolsa@kernel.org>, bpf <bpf@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Aug 29, 2022 at 6:50 PM Yosry Ahmed <yosryahmed@google.com> wrote:
>
> On Mon, Aug 29, 2022 at 6:42 PM Hao Luo <haoluo@google.com> wrote:
> >
> > On Mon, Aug 29, 2022 at 6:07 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> > >
> > > On Mon, Aug 29, 2022 at 3:15 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> > > >
> > > > On Mon, Aug 29, 2022 at 1:08 PM Hao Luo <haoluo@google.com> wrote:
> > > > >
> > > > > On Fri, Aug 26, 2022 at 4:06 PM Yosry Ahmed <yosryahmed@google.com> wrote:
> > > > > >
> > [...]
> > > > > >
> > > > > > -SEC("tp_btf/mm_vmscan_memcg_reclaim_begin")
> > > > > > -int BPF_PROG(vmscan_start, int order, gfp_t gfp_flags)
> > > > > > +SEC("fentry/cgroup_attach_task")
> > > > >
> > > > > Can we select an attachpoint that is more stable? It seems
> > > > > 'cgroup_attach_task' is an internal helper function in cgroup, and its
> > > > > signature can change. I'd prefer using those commonly used tracepoints
> > > > > and EXPORT'ed functions. IMHO their interfaces are more stable.
> > > > >
> > > >
> > > > Will try to find a more stable attach point. Thanks!
> > >
> > > Hey Hao,
> > >
> > > I couldn't find any suitable stable attach points under kernel/cgroup.
> > > Most tracepoints are created using TRACE_CGROUP_PATH which only
> > > invokes the tracepoint if the trace event is enabled, which I assume
> > > is not something we can rely on. Otherwise, there is only
> >
> > Can we explicitly enable the cgroup_attach_task event, just for this
> > test? If it's not easy, I am fine with using fentry.
>
> I see a couple of tests that read from /sys/kernel/debug/tracing, but
> they are mostly reading event ids, I don't see any tests enabling or
> disabling a tracing event, so I am not sure if that's an accepted
> pattern. Also I am not sure if we can rely on tracefs being in that
> path. Andrii, is this considered acceptable?
>

Anyone with thoughts here? Is it acceptable to explicitly enable a
trace event in a BPF selftest to attach to a tracepoint that is only
invoked if the trace event is enabled (e.g. cgroup_attach_task) ?
Otherwise the test program would attach to the fentry of an internal
function, which is more vulnerable to being changed and breaking the
test (until someone updates the test with the new signature).

> >
> > > trace_cgroup_setup_root() and trace_cgroup_destroy_root() which are
> > > irrelevant here. A lot of EXPORT'ed functions are not called in the
> > > kernel, or cannot be invoked from userspace (the test) in a
> > > straightforward way. Even if they did, future changes to such code
> > > paths can also change in the future, so I don't think there is really
> > > a way to guarantee that future changes don't break the test.
> > >
> > > Let me know what you think.
> > >