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

On Fri, Jul 31, 2026 at 6:23=E2=80=AFPM Paul Moore <[email protected]> wr=
ote:
>
> On Fri, Jul 31, 2026 at 6:04=E2=80=AFPM Kumar Kartikeya Dwivedi
> <[email protected]> wrote:
> > On Fri Jul 31, 2026 at 11:49 PM CEST, Paul Moore wrote:
> > > On Fri, Jul 31, 2026 at 5:29=E2=80=AFPM Kumar Kartikeya Dwivedi
> > > <[email protected]> wrote:
> > >> On Fri Jul 31, 2026 at 10:48 PM CEST, Paul Moore wrote:
> > >> > On Fri, Jul 31, 2026 at 4:16=E2=80=AFPM Kumar Kartikeya Dwivedi
> > >> > <[email protected]> wrote:
> > >> >> On Fri Jul 31, 2026 at 10:01 PM CEST, Paul Moore wrote:
> > >> >> > On Fri, Jul 31, 2026 at 3:20=E2=80=AFPM Kumar Kartikeya Dwivedi
> > >> >> > <[email protected]> wrote:
> > >> >> >> On Fri Jul 31, 2026 at 9:05 PM CEST, Paul Moore wrote:
> > >> >> >> > On Fri, Jul 31, 2026 at 2:50=E2=80=AFPM Kumar Kartikeya Dwiv=
edi
> > >> >> >> > <[email protected]> wrote:
> > >> >> >> >> On Fri Jul 31, 2026 at 8:42 PM CEST, Paul Moore wrote:
> > >> >> >> >> > On Fri, Jul 31, 2026 at 2:18=E2=80=AFPM Kumar Kartikeya D=
wivedi
> > >> >> >> >> > <[email protected]> wrote:
> > >> >> >> >> >> On Fri Jul 31, 2026 at 6:59 PM CEST, Paul Moore wrote:
> > >> >> >> >> >> > On Fri, Jul 31, 2026 at 12:32=E2=80=AFPM Kumar Kartike=
ya Dwivedi
> > >> >> >> >> >> > <[email protected]> wrote:
> > >> >> >> >> >> >> On Fri Jul 31, 2026 at 6:02 PM CEST, Paul Moore wrote=
:
> > >> >> >> >> >> >> > On Fri, Jul 31, 2026 at 11:44=E2=80=AFAM Kumar Kart=
ikeya Dwivedi
> > >> >> >> >> >> >> > <[email protected]> wrote:
> > >> >> >> >> >> >> >> On Fri Jul 31, 2026 at 5:30 PM CEST, David Windsor=
 wrote:
> > >> >> >> >> >> >> >> > On Fri, Jul 31, 2026 at 11:17=E2=80=AFAM Paul Mo=
ore <[email protected]> wrote:
>
> ...
>
> > As a consequence, everyone suffers because they first need to satisfy y=
our whims
> > on how all code and kfuncs written thus far are wrong, and need to be m=
oved
> > around ASAP, including the one being proposed.
>
> That's not a reasonble or truthful summary of things, I've only
> requested that David locate his proposed kfunc in
> security/bpf_lsm_kfuncs.c, I never suggested he move any others.
>

Looking at what's left of the kfunc itself, it's basically nothing.
Everything meaningful has been moved into security/ already.

Aside from bpf dynptr ops, what's left is:

if (!name__str)
    return -EINVAL;

if (strncmp(name__str, XATTR_BPF_LSM_SUFFIX, sizeof(XATTR_BPF_LSM_SUFFIX) -=
 1))
    return -EPERM;

if (!xattrs->xattrs)
    return -EOPNOTSUPP;

... then a call to security_lsmxattr_add. Why not move this chunk into
security_lsmxattr_add, and leave the remaining bits, which are pure
bpf, in fs/ for now, and litigate the total placement of all of them
once v7 lands?

> --
> paul-moore.com