On Fri, 2018-07-13 at 16:41 +0200, Daniel Borkmann wrote: > On 07/13/2018 04:26 PM, Paolo Abeni wrote: > > On Fri, 2018-07-13 at 16:08 +0200, Daniel Borkmann wrote: > > > On 07/13/2018 11:55 AM, Paolo Abeni wrote: > > > > Each lockless action currently does its own RCU locking in ->act(). > > > > This is allows using plain RCU accessor, even if the context > > > > is really RCU BH. > > > > > > > > This change drops the per action RCU lock, replace the accessors > > > > with _bh variant, cleans up a bit the surronding code and documents > > > > the RCU status in the relevant header. > > > > No functional nor performance change is intended. > > > > > > > > The goal of this patch is clarifying that the RCU critical section > > > > used by the tc actions extends up to the classifier's caller. > > > > > > > > Signed-off-by: Paolo Abeni <pab...@redhat.com> > > > > > > [...] > > > > diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c > > > > index 06f743d8ed41..ac20266460c0 100644 > > > > --- a/net/sched/act_bpf.c > > > > +++ b/net/sched/act_bpf.c > > > > @@ -45,8 +45,7 @@ static int tcf_bpf(struct sk_buff *skb, const struct > > > > tc_action *act, > > > > tcf_lastuse_update(&prog->tcf_tm); > > > > bstats_cpu_update(this_cpu_ptr(prog->common.cpu_bstats), skb); > > > > > > > > - rcu_read_lock(); > > > > - filter = rcu_dereference(prog->filter); > > > > + filter = rcu_dereference_bh(prog->filter); > > > > if (at_ingress) { > > > > __skb_push(skb, skb->mac_len); > > > > bpf_compute_data_pointers(skb); > > > > @@ -56,7 +55,6 @@ static int tcf_bpf(struct sk_buff *skb, const struct > > > > tc_action *act, > > > > bpf_compute_data_pointers(skb); > > > > filter_res = BPF_PROG_RUN(filter, skb); > > > > } > > > > - rcu_read_unlock(); > > > > > > This conversion is not correct, BPF itself relies on RCU but not RCU-bh > > > flavor. > > > You might probably see a splat if you do e.g. a map lookup with this > > > change in > > > interpreter mode on tx side. > > > > Thank you for your review. > > > > I actually tested with lockdep, and lockdep is happy about it. > > > > The not so nice fact is that many TC modules already use plain RCU > > primitives in the control path (call_rcu, kfree_rcu, etc.) and > > rcu_derefence_bh() in the datapath (e.g. all the classifiers). AFACS, > > despite the mix, this use is safe. > > Hmm, so out of __dev_queue_xmit() we do the RCU-bh read-side. We call > into sch_handle_egress() which calls into tcf_classify() which may be > a matchall one e.g. mall_classify(). It invokes tcf_exts_exec() that > does the a->ops->act() which is the tcf_bpf() from here. If you then > call a helper like bpf_map_lookup_elem(), there's a WARN_ON_ONCE() for > !rcu_read_lock_held() since all of BPF is under normal RCU flavor. Why > would that not trigger?
Because the basic sample I used did not call any other ebpf helper beyond bpf_redirect(), I guess. I see rcu_read_lock() is still needed here, thanks. As a side note, after: rcu_read_lock_bh() rcu_read_lock(); both rcu_dereference() and rcu_derefernce_bh() are considered fine by lockdep. Cheers, Paolo