Re: [PATCH net-next V7 4/4] net/sched: Introduce act_tunnel_key

[John Fastabend]

On 16-09-09 06:19 AM, Eric Dumazet wrote:
> On Thu, 2016-09-08 at 22:30 -0700, Cong Wang wrote:
>> On Thu, Sep 8, 2016 at 9:15 AM, John Fastabend  
>> wrote:
>>>
>>> This should be rtnl_derefence(t->params) and drop the read_lock/unlock
>>> pair. This is always called with RTNL lock unless you have a path I'm
>>> not seeing.
>>
>> You missed the previous discussion on V6, John.
>>
>> BTW, you really should follow the whole discussion instead of
>> jumping in the middle, like what you did for my patchset.
>> I understand you are eager to comment, but please don't waste
>> others' time in this way Please.
> 
> But John is right, and he definitely is welcome to give his feedback
> even at V13 if he wants to.
> 
> tunnel_key_dump() is called with RTNL being held.
> 
> Take a deep breath, vacations, and come back when you are relaxed.
> 
> Thanks.
> 
> 

Also v6 discussion was around cleanup() call back I see nothing about
the dump() callbacks. And if there was it wasn't fixed so it should
be resolved.

Anyways Dave/Hadar feel free to submit a follow up patch or v8 it
doesn't much matter to me as noted in the original post.

.John

Re: [PATCH net-next V7 4/4] net/sched: Introduce act_tunnel_key

[Eric Dumazet]

On Thu, 2016-09-08 at 22:30 -0700, Cong Wang wrote:
> On Thu, Sep 8, 2016 at 9:15 AM, John Fastabend  
> wrote:
> >
> > This should be rtnl_derefence(t->params) and drop the read_lock/unlock
> > pair. This is always called with RTNL lock unless you have a path I'm
> > not seeing.
> 
> You missed the previous discussion on V6, John.
> 
> BTW, you really should follow the whole discussion instead of
> jumping in the middle, like what you did for my patchset.
> I understand you are eager to comment, but please don't waste
> others' time in this way Please.

But John is right, and he definitely is welcome to give his feedback
even at V13 if he wants to.

tunnel_key_dump() is called with RTNL being held.

Take a deep breath, vacations, and come back when you are relaxed.

Thanks.

Re: [PATCH net-next V7 4/4] net/sched: Introduce act_tunnel_key

[Cong Wang]

On Thu, Sep 8, 2016 at 9:15 AM, John Fastabend  wrote:
>
> This should be rtnl_derefence(t->params) and drop the read_lock/unlock
> pair. This is always called with RTNL lock unless you have a path I'm
> not seeing.

You missed the previous discussion on V6, John.

BTW, you really should follow the whole discussion instead of
jumping in the middle, like what you did for my patchset.
I understand you are eager to comment, but please don't waste
others' time in this way Please.

Re: [PATCH net-next V7 4/4] net/sched: Introduce act_tunnel_key

[John Fastabend]

On 16-09-08 06:23 AM, Hadar Hen Zion wrote:
> From: Amir Vadai 
> 
> 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:
> 
> $ tc filter add dev net0 protocol ip parent : \
> flower \
>   ip_proto 1 \
>   dst_ip 11.11.11.2 \
> action tunnel_key set \
>   src_ip 11.11.0.1 \
>   dst_ip 11.11.0.2 \
>   id 11 \
> action mirred egress redirect dev vxlan0
> 
> Signed-off-by: Amir Vadai 
> Signed-off-by: Hadar Hen Zion 
> Reviewed-by: Shmulik Ladkani 
> Acked-by: Jamal Hadi Salim 
> ---

[...]

> +static void tunnel_key_release(struct tc_action *a, int bind)
> +{
> + struct tcf_tunnel_key *t = to_tunnel_key(a);
> + struct tcf_tunnel_key_params *params;
> +
> + rcu_read_lock();
> + params = rcu_dereference(t->params);
> +
> + if (params->tcft_action == TCA_TUNNEL_KEY_ACT_SET)
> + dst_release(>tcft_enc_metadata->dst);
> +
> + kfree_rcu(params, rcu);
> +
> + rcu_read_unlock();
> +}
> +

Same comment as Eric, you better own the action or else this could
race.

> +
> +static int tunnel_key_dump(struct sk_buff *skb, struct tc_action *a,
> +int bind, int ref)
> +{
> + unsigned char *b = skb_tail_pointer(skb);
> + struct tcf_tunnel_key *t = to_tunnel_key(a);
> + struct tcf_tunnel_key_params *params;
> + struct tc_tunnel_key opt = {
> + .index= t->tcf_index,
> + .refcnt   = t->tcf_refcnt - ref,
> + .bindcnt  = t->tcf_bindcnt - bind,
> + };
> + struct tcf_t tm;
> + int ret = -1;
> +
> + rcu_read_lock();
> + params = rcu_dereference(t->params);

This should be rtnl_derefence(t->params) and drop the read_lock/unlock
pair. This is always called with RTNL lock unless you have a path I'm
not seeing.


> +
> + opt.t_action = params->tcft_action;
> + opt.action = params->action;
> +
> + if (nla_put(skb, TCA_TUNNEL_KEY_PARMS, sizeof(opt), ))
> + goto nla_put_failure;
> +
> + if (params->tcft_action == TCA_TUNNEL_KEY_ACT_SET) {
> + struct ip_tunnel_key *key =
> + >tcft_enc_metadata->u.tun_info.key;
> + __be32 key_id = tunnel_id_to_key32(key->tun_id);
> +
> + if (nla_put_be32(skb, TCA_TUNNEL_KEY_ENC_KEY_ID, key_id) ||
> + tunnel_key_dump_addresses(skb,
> +   
> >tcft_enc_metadata->u.tun_info))
> + goto nla_put_failure;
> + }
> +
> + tcf_tm_dump(, >tcf_tm);
> + if (nla_put_64bit(skb, TCA_TUNNEL_KEY_TM, sizeof(tm),
> +   , TCA_TUNNEL_KEY_PAD))
> + goto nla_put_failure;
> +
> + ret = skb->len;
> + goto out;
> +
> +nla_put_failure:
> + nlmsg_trim(skb, b);
> +out:
> + rcu_read_unlock();
> +
> + return ret;
> +}
> +

I don't really care if you roll the above two rcu cleanups on top of
the patch as a follow up or roll a v8. But I think we should get the
annotation right here so its clear later.

.John

Re: [PATCH net-next V7 4/4] net/sched: Introduce act_tunnel_key

[Eric Dumazet]

On Thu, 2016-09-08 at 16:23 +0300, Hadar Hen Zion wrote:
> From: Amir Vadai 
> 
> This action could be used before redirecting packets to a shared tunnel
> device, or when redirecting packets arriving from a such a device.


> +static void tunnel_key_release(struct tc_action *a, int bind)
> +{
> + struct tcf_tunnel_key *t = to_tunnel_key(a);
> + struct tcf_tunnel_key_params *params;
> +
> + rcu_read_lock();
> + params = rcu_dereference(t->params);
> +
> + if (params->tcft_action == TCA_TUNNEL_KEY_ACT_SET)
> + dst_release(>tcft_enc_metadata->dst);
> +
> + kfree_rcu(params, rcu);
> +
> + rcu_read_unlock();
> +}

Note that you own the action here, so technically speaking no writer
could possibly modify t->params while this function is running.

So you could use 

params = rcu_dereference_protected(t->params, 1)

(I could not find a way to express the 'I own this action and am the
last user' for LOCKDEP sake so I used 1)

instead of

rcu_read_lock();
params = rcu_dereference(t->params);
rcu_read_unlock();


But this is a very minor detail, and this patch looks fine to me, thanks
a lot for your patience Hadar .

Acked-by: Eric Dumazet