On Sun, Aug 2, 2026 at 10:46 AM Paul Moore <[email protected]> wrote: > On Fri, Jul 31, 2026 at 7:11 PM David Windsor <[email protected]> wrote: > > On Fri, Jul 31, 2026 at 6:23 PM Paul Moore <[email protected]> wrote: > > > On Fri, Jul 31, 2026 at 6:04 PM 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 PM 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 PM 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 PM 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 PM Kumar Kartikeya Dwivedi > > > > >> >> >> > <[email protected]> wrote: > > > > >> >> >> >> On Fri Jul 31, 2026 at 8:42 PM CEST, Paul Moore wrote: > > > > >> >> >> >> > On Fri, Jul 31, 2026 at 2:18 PM Kumar Kartikeya Dwivedi > > > > >> >> >> >> > <[email protected]> wrote: > > > > >> >> >> >> >> On Fri Jul 31, 2026 at 6:59 PM CEST, Paul Moore wrote: > > > > >> >> >> >> >> > On Fri, Jul 31, 2026 at 12:32 PM Kumar Kartikeya > > > > >> >> >> >> >> > 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 AM Kumar Kartikeya > > > > >> >> >> >> >> >> > 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 AM Paul Moore > > > > >> >> >> >> >> >> >> > <[email protected]> wrote: > > > > > > ... > > > > > > > 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
