On Mon Jul 20, 2026 at 8:27 PM CEST, Kumar Kartikeya Dwivedi wrote: > 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.
Also, perhaps it makes sense to use set/get naming for this one too, to keep it consistent with other ones?
