On Mon, Jul 20, 2026 at 2:30 PM Kumar Kartikeya Dwivedi <[email protected]> wrote: > > 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?
I considered that, but we're only allowing one to initialize the xattr on the inode here. Once it's been initialized, one uses bpf_dentry_set_xattr.
