[PATCH v6 bpf-next 3/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling

Paul Moore paul at paul-moore.com
Fri Jul 31 15:17:04 UTC 2026


On Thu, Jul 30, 2026 at 8:01 PM David Windsor <dwindsor at gmail.com> wrote:
> On Thu, Jul 30, 2026 at 7:53 PM Paul Moore <paul at paul-moore.com> wrote:
> >
> > Based on our discussion in the v5 patchset, I was expecting to see
> > this under security/; did something happen, or was there some
> > confusion?
> >
>
> Nothing happened, perhaps some confusion. I was basing the placement
> off of Kumar's comment in v5:
>
> > I don't think we should do that in v6 though. What you're describing affects all
> other xattr kfuncs. That's a broader discussion we should have separately when
> folks are back from vacation, and more importantly involve FS folks where the
> code currently lives. As you say yourself, the lines are blurry, xattrs are as
> much a filesystem concept.
>
> My take on this was, leave it in fs/ for now and then litigate the
> placement of all of the fs-related kfuncs after bpf_init_inode_xattr
> lands.
>
> Happy to place this in security/ in v7, if that's preferred. Apologies
> if I misread the thread.

Okay, it looks like there was some confusion/misunderstanding.

My understanding of Kumar's comments was that he was referring to the
exisiting LSM related kfuncs that are located in fs/bpf_fs_kfuncs.c,
not necessarily the new kfunc you are proposing in this patchset.
Kumar is welcome to correct either one or both of us, if we read that
wrong :)

However, regardless of Kumar's intent, speaking as the LSM maintainer,
my stance on this is that the kfunc you are proposing must live in
security/bpf_lsm_kfuncs.c to be acceptable.

-- 
paul-moore.com



More information about the Linux-security-module-archive mailing list