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

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] [day] [month] [year] [list]

Message-ID: <1513934885.2913.13.camel@redhat.com>
Date:   Fri, 22 Dec 2017 10:28:05 +0100
From:   Davide Caratti <dcaratti@...hat.com>
To:     David Miller <davem@...emloft.net>
Cc:     xiyou.wangcong@...il.com, jiri@...lanox.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] net/sched: act_csum: don't use spinlock
 in the fast path

On Wed, 2017-12-13 at 16:23 -0500, David Miller wrote:
> From: Davide Caratti <dcaratti@...hat.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