Re: [PATCH net-next 2/2] net/sched: act_csum: don't use spinlock in the fast path

[Davide Caratti <dcaratti@redhat.com>]

On Wed, 2017-12-13 at 16:23 -0500, David Miller wrote:
> From: Davide Caratti <dcaratti@redhat.com>
> Date: Wed, 13 Dec 2017 10:48:38 +0100
> 
> > Then, in the data path, use READ_ONCE() to
> > read those values, to avoid lock contention among multiple readers.
>  ...
> > @@ -544,14 +543,12 @@ static int tcf_csum(struct sk_buff *skb, const struct tc_action *a,
> >  
> >       tcf_lastuse_update(&p->tcf_tm);
> >       bstats_cpu_update(this_cpu_ptr(p->common.cpu_bstats), skb);
> > -     spin_lock(&p->tcf_lock);
> > -     action = p->tcf_action;
> > -     update_flags = p->update_flags;
> > -     spin_unlock(&p->tcf_lock);
> >  
> > +     action = READ_ONCE(p->tcf_action);
> >       if (unlikely(action == TC_ACT_SHOT))
> >               goto drop;
> >  
> > +     update_flags = READ_ONCE(p->update_flags);
> >       switch (tc_skb_protocol(skb)) {
> >       case cpu_to_be16(ETH_P_IP):
> >               if (!tcf_csum_ipv4(skb, update_flags))

hi David, thank you for replying!

> That's not why the lock is here.
> 
> We must read both action and flags atomically so that they are consistent
> with eachother.
> 
> We must never use action from one configuration change and flags from
> yet another.

I was (erroneously) assuming that such behavior was acceptable, since it's
present almost in all other TC actions, even those where tcf_lock is used.
But agree, it's better not to introduce a race in a place where it's not
present.

> Find a way to load both of these values with a single cpu load, then you
> can legally remove the lock.

act_tunnel_key seems a good example for this, I will send a v2 soon.

-- 
davide