On Mon Jul 20, 2026 at 8:12 PM CEST, David Windsor wrote: > On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <[email protected]> wrote: >> >> >> I'm sorry David, now that I'm seeing this function again, especially >> with the LSM specific bits extracted into a LSM function, this absolutely >> belongs somewhere under security/. It's only callable from within a >> BPF LSM callback and all it does outside of some BPF pointer boilerplate >> is call right back into a LSM helper function. >> >> If the BPF maintainers aren't willing to accept that, then we will all >> need to find another way. >> > > Where this code lands doesn't matter to me, so I'll stay out of the > decision of where it lives. > > If this kfunc goes to security/, would we also want to move eg > bpf_set_dentry_xattr similarly? > > I'll roll v6 of this series meanwhile and we'll see what the BPF > maintainers say.
I don't think there was any preference expressed from the BPF side. Logically, one cannot be faulted for adding a kfunc to set the xattr for inode in the same file where similar kfuncs to set xattr on other FS objects / entities exist. The question about bpf_set_dentry_xattr is thus valid. Anyway, I will leave it to Paul and Christian to decide between themselves where it makes most sense for this one to live.
