netdev - Re: [PATCH net-next 2/4] tc/act: remove unneeded RCU lock in action callback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e30d29559193c68e5b6e0fe50ed3ce0a06eee01d.camel@redhat.com>
Date:   Fri, 13 Jul 2018 17:00:51 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org
Cc:     Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Alexei Starovoitov <ast@...nel.org>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Subject: Re: [PATCH net-next 2/4] tc/act: remove unneeded RCU lock in action
 callback

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 <pabeni@...hat.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