From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Paul Moore" <paul@paul-moore.com>
Cc: <torvalds@linux-foundation.org>, <bpf@vger.kernel.org>,
<daniel@iogearbox.net>, <andrii@kernel.org>, <eddyz87@gmail.com>,
<memxor@gmail.com>, <linux-security-module@vger.kernel.org>,
<brauner@kernel.org>, <dwindsor@gmail.com>, <kpsingh@kernel.org>,
<matt@bobrowski.net>
Subject: Re: [GIT PULL] BPF changes for 7.4
Date: Thu, 22 Oct 2026 03:18:32 +0000 [thread overview]
Message-ID: <DMB1J3GT728H.2KEOF9XKYSGEO@gmail.com> (raw)
In-Reply-To: <CAHC9VhQz1aam-P+xh8CT=3V9fNtdrcFSZ6VEOWUGx1cKWV+WYQ@mail.gmail.com>
On Wed, Oct 21, 2026 at 06:26 PM Paul Moore <paul@paul-moore.com> wrote:
>
> "... just as the maintenence of bpf_fs_funcs.c falls to the VFS." is
> the rest of that sentence. We're not asking for a type of
> cross-subsystem relationship without precedent.
That file has a history.
Nov 2023. Song added bpf_get_file_xattr() for BPF LSM progs to
kernel/trace/bpf_trace.c:
commit ac9c05e0e453 ("bpf: Add kfunc bpf_get_file_xattr")
Mar 2024. Matt's v2 was adding more kfuncs for BPF LSM progs next to it.
Christian replied:
"Conditio sine qua non is that all such kfunc definitions must live in
the respective file in fs/. They won't be hidden somewhere in
kernel/bpf/."
https://lore.kernel.org/bpf/20240306-zeitumstellung-darben-7857ca9817c0@brauner/
Jul 2024. After discussions with Christian at LSFMMBPF Matt created
fs/bpf_fs_kfuncs.c in v3:
commit d08e2045ebf0 ("bpf: introduce new VFS based BPF kfuncs")
Christian acked it and asked for more:
"I also wouldn't mind follow-up patches that move the xattr bpf kfuncs
under fs/ as well."
https://lore.kernel.org/bpf/20240726-clown-geantwortet-eb29a17890c3@brauner/
Aug 2024. Song moved bpf_get_file_xattr() there:
commit fa4e5afa9758 ("bpf: Move bpf_get_file_xattr to fs/bpf_fs_kfuncs.c")
"We are putting all fs kfuncs in fs/bpf_fs_kfuncs.c."
Every xattr kfunc since then went there: bpf_get_dentry_xattr(),
bpf_{set,remove}_dentry_xattr(), bpf_cgroup_read_xattr() from Song,
bpf_sock_read_xattr() from Christian.
David's v1 in April put the new one next to them.
It cannot be in fs/ and in security/ at the same time.
> One might question the placement of some of the other BPF kfuncs
> located in bpf_fs_kfuncs.c as the file is conditionally built based on
> CONFIG_BPF_LSM as opposed to CONFIG_BPF_SYSCALL or some other generic
> BPF Kconfig knob, but there is no sense in worrying about that until
> we settle this.
Back in 2024 all kfuncs in that file were for BPF LSM progs. Matt's v2
from Mar 2024 even called the set lsm_kfunc_set_ids. They moved to fs/
anyway. Hence CONFIG_BPF_LSM.
> The lsm_get_xattr_slot() function is intended for use by LSMs
> (it's not an external LSM "hook") and the fact that the kfunc in
> question calls into it (and not a single VFS function) is one of the
> reasons why I'm arguing strongly that this is purely a LSM kfunc and
> should be located in security/bpf_lsm_funcs.c.
BPF LSM is in kernel/bpf/bpf_lsm.c since 2020 and includes lsm_hooks.h
since then. bpf_bprm_opts_set(), bpf_ima_inode_hash(), bpf_ima_file_hash()
helpers that only BPF LSM progs can call are there too.
security/bpf/hooks.c is 43 lines that register it.
I don't feel we will converge here.
Linus,
it's your call. If you think the kfunc should move I'll send a follow up.
bpf progs don't see which file a kfunc is in, so there is no need to
hold the pull request for that.
imo xattrs are VFS territory.
next prev parent reply other threads:[~2026-10-22 3:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 21:01 [GIT PULL] BPF changes for 7.4 Alexei Starovoitov
2026-10-21 21:26 ` Paul Moore
2026-10-21 22:45 ` Alexei Starovoitov
2026-10-22 1:26 ` Paul Moore
2026-10-22 3:18 ` Alexei Starovoitov [this message]
2026-10-22 11:04 ` Christian Brauner
2026-10-24 0:00 ` pr-tracker-bot
2026-10-24 0:00 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DMB1J3GT728H.2KEOF9XKYSGEO@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=dwindsor@gmail.com \
--cc=eddyz87@gmail.com \
--cc=kpsingh@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matt@bobrowski.net \
--cc=memxor@gmail.com \
--cc=paul@paul-moore.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.