netdev - Re: [PATCH net-next V3 4/4] net/sched: Introduce act_tunnel

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: <1472147334.14381.149.camel@edumazet-glaptop3.roam.corp.google.com>
Date:   Thu, 25 Aug 2016 10:48:54 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Hadar Hen Zion <hadarh@...lanox.com>
Cc:     "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Jiri Pirko <jiri@...lanox.com>, Jiri Benc <jbenc@...hat.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Shmulik Ladkani <shmulik.ladkani@...il.com>,
        Tom Herbert <tom@...bertland.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        Amir Vadai <amirva@...lanox.com>, Amir Vadai <amir@...ai.me>
Subject: Re: [PATCH net-next V3 4/4] net/sched: Introduce act_tunnel_key

On Thu, 2016-08-25 at 19:13 +0300, Hadar Hen Zion wrote:
> From: Amir Vadai <amir@...ai.me>
> 
> This action could be used before redirecting packets to a shared tunnel
> device, or when redirecting packets arriving from a such a device.
> 
> The action will release the metadata created by the tunnel device
> (decap), or set the metadata with the specified values for encap
> operation.
> 
> For example, the following flower filter will forward all ICMP packets
> destined to 11.11.11.2 through the shared vxlan device 'vxlan0'. Before
> redirecting, a metadata for the vxlan tunnel is created using the
> tunnel_key action and it's arguments:

....

> +
> +static int tunnel_key_act(struct sk_buff *skb, const struct tc_action *a,
> +			  struct tcf_result *res)
> +{
> +	struct tcf_tunnel_key *t = to_tunnel_key(a);
> +	int action;
> +
> +	spin_lock(&t->tcf_lock);
> +	tcf_lastuse_update(&t->tcf_tm);
> +	bstats_update(&t->tcf_bstats, skb);
> +	action = t->tcf_action;
> +
> +	switch (t->tcft_action) {
> +	case TCA_TUNNEL_KEY_ACT_RELEASE:
> +		skb_dst_set_noref(skb, NULL);
> +		break;
> +	case TCA_TUNNEL_KEY_ACT_SET:
> +		skb_dst_set_noref(skb, &t->tcft_enc_metadata->dst);
> +		break;
> +	default:
> +		WARN_ONCE(1, "Bad tunnel_key action.\n");
> +		break;
> +	}
> +
> +	spin_unlock(&t->tcf_lock);
> +	return action;


Please find a better way than using a spinlock in this hot path.

Maybe looking at 
2ee22a90c7afac265bb6f7abea610b938195e2b8 net_sched: act_mirred: remove spinlock in fast path
56e5d1ca183d8616fab377d7d466c244b4dbb3b9 net_sched: act_gact: remove spinlock in fast path
8f2ae965b7ef4f4ddab6110f06388e270723d694 net_sched: act_gact: read tcfg_ptype once
cc6510a9504fd3c03d76bd68d99653148342eecc net_sched: act_gact: use a separate packet counters for gact_determ()
cef5ecf96b28dc91c4e9f398a336c578fb9e1a0c net_sched: act_gact: make tcfg_pval non zero
519c818e8fb646eef1e8bfedd18519bec47bc9a9 net: sched: add percpu stats to actions