On 05/14, Eric Dumazet wrote: > > > On 5/14/19 7:27 PM, Alexei Starovoitov wrote: > > > what about activate_effective_progs() ? > > I wouldn't want to lose the annotation there. > > but then array_free will lose it? It would not have have it because the input is the result of bpf_prog_array_alloc() which returns kmalloc'd pointer (and is not bound to an rcu section).
> > in some cases it's called without mutex in a destruction path. Hm, can you point me to this place? I think I checked every path, maybe I missed something subtle. I'll double check. > > also how do you propose to solve different 'mtx' in > > lockdep_is_held(&mtx)); ? > > passing it through the call chain is imo not clean. Every caller would know which mutex protects it. As Eric said below, I'm adding a bunch of xxx_dereference macros that hardcode mutex, like the existing rtnl_dereference. > Usage of RCU api in BPF is indeed a bit strange and lacks lockdep support. > > Looking at bpf_prog_array_copy_core() for example, it looks like the __rcu > in the first argument is not needed, since the caller must have done the > proper dereference already, > and the caller knows which mutex is protecting its > rcu_dereference_protected() for the writer sides. > > bpf_prog_array_copy_core() should manipulate standard pointers, with no __rcu > stuff. > > The analogy in net/ are probably the rtnl_dereference() users.
