[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAADnVQK111J3b-4gauYkptFf51fhYQn2J78dH8QiwdSigiRuJw@mail.gmail.com>
Date: Mon, 21 Apr 2025 09:13:03 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Daniel Xu <dxu@...uu.xyz>
Cc: Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>,
David Ahern <dsahern@...nel.org>, Steven Rostedt <rostedt@...dmis.org>,
Dave Hansen <dave.hansen@...ux.intel.com>, Quentin Monnet <qmo@...nel.org>,
Alexei Starovoitov <ast@...nel.org>, Christian Brauner <brauner@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>, Jakub Kicinski <kuba@...nel.org>,
Jozsef Kadlecsik <kadlec@...filter.org>, Jesper Dangaard Brouer <hawk@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Daniel Borkmann <daniel@...earbox.net>,
Namhyung Kim <namhyung@...nel.org>, Eric Dumazet <edumazet@...gle.com>, Sean Young <sean@...s.org>,
X86 ML <x86@...nel.org>, Alexander Viro <viro@...iv.linux.org.uk>,
Masami Hiramatsu <mhiramat@...nel.org>, Matt Bobrowski <mattbobrowski@...gle.com>,
Paolo Abeni <pabeni@...hat.com>, "David S. Miller" <davem@...emloft.net>,
Arnaldo Carvalho de Melo <acme@...nel.org>, KP Singh <kpsingh@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>, Song Liu <song@...nel.org>,
Andrii Nakryiko <andrii@...nel.org>, Borislav Petkov <bp@...en8.de>,
Pablo Neira Ayuso <pablo@...filter.org>, Mauro Carvalho Chehab <mchehab@...nel.org>, Ingo Molnar <mingo@...hat.com>,
Martin KaFai Lau <martin.lau@...ux.dev>, Eduard <eddyz87@...il.com>,
Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>, Jan Kara <jack@...e.cz>, Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Simon Horman <horms@...nel.org>,
Network Development <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, linux-media@...r.kernel.org,
Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
"linux-perf-use." <linux-perf-users@...r.kernel.org>,
linux-trace-kernel <linux-trace-kernel@...r.kernel.org>,
netfilter-devel <netfilter-devel@...r.kernel.org>, coreteam@...filter.org
Subject: Re: [RFC bpf-next 11/13] treewide: bpf: Export symbols used by verifier
On Tue, Apr 8, 2025 at 8:35 PM Daniel Xu <dxu@...uu.xyz> wrote:
>
> This commit EXPORT_SYMBOL_GPL()'s all the unresolved symbols from verifier.o.
> This is necessary to support loads and reloads of the verifier at
> runtime.
>
> The list of symbols was generated using:
>
> nm -u kernel/bpf/verifier.o | grep -ve "__asan\|__ubsan\|__kasan" | awk '{print $2}'
>
> Signed-off-by: Daniel Xu <dxu@...uu.xyz>
> ---
> arch/x86/net/bpf_jit_comp.c | 2 ++
> drivers/media/rc/bpf-lirc.c | 1 +
> fs/bpf_fs_kfuncs.c | 4 ++++
> kernel/bpf/bpf_iter.c | 1 +
> kernel/bpf/bpf_lsm.c | 5 +++++
> kernel/bpf/bpf_struct_ops.c | 2 ++
> kernel/bpf/btf.c | 40 +++++++++++++++++++++++++++++++++++++
> kernel/bpf/cgroup.c | 4 ++++
> kernel/bpf/core.c | 29 +++++++++++++++++++++++++++
> kernel/bpf/disasm.c | 4 ++++
> kernel/bpf/helpers.c | 2 ++
> kernel/bpf/local_storage.c | 2 ++
> kernel/bpf/log.c | 12 +++++++++++
> kernel/bpf/map_iter.c | 1 +
> kernel/bpf/memalloc.c | 3 +++
> kernel/bpf/offload.c | 10 ++++++++++
> kernel/bpf/syscall.c | 7 +++++++
> kernel/bpf/tnum.c | 20 +++++++++++++++++++
> kernel/bpf/token.c | 1 +
> kernel/bpf/trampoline.c | 5 +++++
> kernel/events/callchain.c | 3 +++
> kernel/trace/bpf_trace.c | 9 +++++++++
> lib/error-inject.c | 2 ++
> net/core/filter.c | 26 ++++++++++++++++++++++++
> net/core/xdp.c | 2 ++
> net/netfilter/nf_bpf_link.c | 1 +
> 26 files changed, 198 insertions(+)
Patches 1-10 look ok. Moving the code around and few targeted
exports are fine,
but this patch goes too far.
At least btf.c, log.c, tnum.c and may be others should be a part
of the module.
Then check_sock_access() can be refactored into callbacks
to avoid exports in filter.c
We can approach it from the pov of minimizing exports,
but such steps won't give us clarity on how portable such
modular verifier will be.
Other questions to answer is whether maps should be in the module too.
Modules can provide their kfuncs already, so existing kfuncs
can stay where they are.
Namespacing into "bpf_internal" as Stanislav suggested is
a good thing too with a warning somewhere in Documentation/bpf/
that these must only be used by the verifier.
Powered by blists - more mailing lists