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

On Sun, Aug 2, 2026 at 10:46 AM Paul Moore [off-list ref] wrote:

On Fri, Jul 31, 2026 at 7:11 PM David Windsor [off-list ref] wrote:

quoted

On Fri, Jul 31, 2026 at 6:23 PM Paul Moore [off-list ref] wrote:

quoted

On Fri, Jul 31, 2026 at 6:04 PM Kumar Kartikeya Dwivedi
[off-list ref] wrote:

quoted

On Fri Jul 31, 2026 at 11:49 PM CEST, Paul Moore wrote:

quoted

On Fri, Jul 31, 2026 at 5:29 PM Kumar Kartikeya Dwivedi
[off-list ref] wrote:

quoted

On Fri Jul 31, 2026 at 10:48 PM CEST, Paul Moore wrote:

quoted

On Fri, Jul 31, 2026 at 4:16 PM Kumar Kartikeya Dwivedi
[off-list ref] wrote:

quoted

On Fri Jul 31, 2026 at 10:01 PM CEST, Paul Moore wrote:

quoted

On Fri, Jul 31, 2026 at 3:20 PM Kumar Kartikeya Dwivedi
[off-list ref] wrote:

quoted

On Fri Jul 31, 2026 at 9:05 PM CEST, Paul Moore wrote:

quoted

On Fri, Jul 31, 2026 at 2:50 PM Kumar Kartikeya Dwivedi
[off-list ref] wrote:

quoted

On Fri Jul 31, 2026 at 8:42 PM CEST, Paul Moore wrote:

quoted

On Fri, Jul 31, 2026 at 2:18 PM Kumar Kartikeya Dwivedi
[off-list ref] wrote:

quoted

On Fri Jul 31, 2026 at 6:59 PM CEST, Paul Moore wrote:

quoted

On Fri, Jul 31, 2026 at 12:32 PM Kumar Kartikeya Dwivedi
[off-list ref] wrote:

quoted

On Fri Jul 31, 2026 at 6:02 PM CEST, Paul Moore wrote:

quoted

On Fri, Jul 31, 2026 at 11:44 AM Kumar Kartikeya Dwivedi
[off-list ref] wrote:

quoted

On Fri Jul 31, 2026 at 5:30 PM CEST, David Windsor wrote:

quoted

On Fri, Jul 31, 2026 at 11:17 AM Paul Moore [off-list ref] wrote:

...

quoted

As a consequence, everyone suffers because they first need to satisfy your whims
on how all code and kfuncs written thus far are wrong, and need to be moved
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?

Thanks David, but my comments and decision are based on the kfunc as a
whole, not necessarily how the work is divided between the kfunc and
the LSM hook it calls; shuffling bits of code between the two doesn't
change the character of the function.

To be clear, this means I would still need to see the proposed kfunc
in security/bpf_lsm_kfuncs.c to be deemed acceptable.  Also to be
clear, I'm not suggesting, or even requiring, that you move any of the
other existing kfuncs in your patchset; I never suggested that as a
requirement for your work.

-- 
paul-moore.com