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: > >> > > >> > ... > >> > > >> >> Yes, I understand you feel it should be placed under security/. You are > >> >> entitled > >> >> to your opinion. > >> >> > >> >> No, I do not think the newly added kfunc is a big enough layering > >> >> violation such > >> >> that we need to do it ASAP, disregarding everything else outlined > >> >> above. I am > >> >> sure you see that too. There are several other instances of similar > >> >> kfuncs. > >> >> > >> >> Therefore, please attempt to meet me halfway here. > >> > > >> > I'm happy to work with you, and/or anyone else, who wants to work on > >> > finding a way to test kfuncs that live in security/bpf_lsm_kfuncs.c. > >> > >> Right, and for that file to exist, you need to get everyone (FS, BPF > >> folks) to > >> agree on whether placing all such kfuncs there makes sense. It is not for > >> both > >> of us to decide on our own. So let's revisit this whole topic once you've > >> done > >> that exercise. > > > > The kfunc that David has proposed must be located in > > security/bpf_lsm_kfuncs.c, similar to the VFS kfuncs and > > fs/bpf_fs_kfuncs.c. If you read David's bpf_init_inode_xattr() kfunc > > Sigh. > > I now went and read the archives, and Christian already told you no before > [0], > which I missed in my first read. So two people whom this code affects already > objected to your proposal.
As mentioned previously, David's kfunc has nothing to do with the VFS. Look at the code if you haven't already and you'll see what I mean. The only relevance to the VFS is the fact that "inode" and "xattr" are used in the name; David's currently proposed kfunc is an LSM kfunc, not a VFS kfunc. If you find yourself required to abide by Christian's comment, despite this not being a VFS kfunc, that's fine, but this puts us at a stalemate and David will need to find another approach for his work. -- paul-moore.com
