> On Jan 30, 2025, at 12:23 PM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: [...] >>> For all these reasons I don't like this approach. >>> This "generality" doesn't make it cleaner or easier to extend. >>> For the patch 6... just repeat what specialize_kfunc() >>> currently does for dynptr ? >> >> Yes, specialize_kfunc() can handle this. But we will need to use >> d_inode_locked_hooks from 6/7 in specialize_kfunc(). It works, >> but it is not clean (to me). > > I'm missing why that would be necessary to cross the layers > so much. I guess the code will tell. > Pls send an rfc to illustrate the unclean part. The actual code is actually a lot cleaner than I thought. We just need to use the bpf_lsm_has_d_inode_locked() helper in verifier.c. Thanks, Song > >> I will revise this set so that the polymorphism logic in handled >> in specialize_kfunc(). For longer term, maybe we should discuss >> "move some logic from verifier core to kfuncs" in the upcoming >> LSF/MM/BPF? > > imo such topic is too narrow and detail oriented. > There is not much to gain from discussing it at lsfmm. > email works well for such discussions.
