[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220412094923.0abe90955e5db486b7bca279@kernel.org>
Date: Tue, 12 Apr 2022 09:49:23 +0900
From: Masami Hiramatsu <mhiramat@...nel.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>,
Steven Rostedt <rostedt@...dmis.org>
Cc: Jiri Olsa <jolsa@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...omium.org>
Subject: Re: [RFC bpf-next 4/4] selftests/bpf: Add attach bench test
On Mon, 11 Apr 2022 15:15:40 -0700
Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
> > +#define DEBUGFS "/sys/kernel/debug/tracing/"
> > +
> > +static int get_syms(char ***symsp, size_t *cntp)
> > +{
> > + size_t cap = 0, cnt = 0, i;
> > + char *name, **syms = NULL;
> > + struct hashmap *map;
> > + char buf[256];
> > + FILE *f;
> > + int err;
> > +
> > + /*
> > + * The available_filter_functions contains many duplicates,
> > + * but other than that all symbols are usable in kprobe multi
> > + * interface.
> > + * Filtering out duplicates by using hashmap__add, which won't
> > + * add existing entry.
> > + */
> > + f = fopen(DEBUGFS "available_filter_functions", "r");
>
> I'm really curious how did you manage to attach to everything in
> available_filter_functions because when I'm trying to do that I fail.
> available_filter_functions has a bunch of functions that should not be
> attachable (e.g., notrace functions). Look just at __bpf_tramp_exit:
>
> void notrace __bpf_tramp_exit(struct bpf_tramp_image *tr);
Hmm, this sounds like a bug in ftrace side. IIUC, the
"available_filter_functions" only shows the functions which is NOT
instrumented by mcount, we should not see any notrace functions on it.
Technically, this is done by __no_instrument_function__ attribute.
#if defined(CC_USING_HOTPATCH)
#define notrace __attribute__((hotpatch(0, 0)))
#elif defined(CC_USING_PATCHABLE_FUNCTION_ENTRY)
#define notrace __attribute__((patchable_function_entry(0, 0)))
#else
#define notrace __attribute__((__no_instrument_function__))
#endif
>
> So first, curious what I am doing wrong or rather why it succeeds in
> your case ;)
>
> But second, just wanted to plea to "fix" available_filter_functions to
> not list stuff that should not be attachable. Can you please take a
> look and checks what's going on there and why do we have notrace
> functions (and what else should *NOT* be there)?
Can you share how did you reproduce the issue? I'll check it.
Thank you,
--
Masami Hiramatsu <mhiramat@...nel.org>
Powered by blists - more mailing lists