netdev - Re: [PATCH net-next RFC v2 1/3] lwt: infrastructure to support light weight tunnels

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: <5584507C.2000303@brocade.com>
Date:	Fri, 19 Jun 2015 18:25:16 +0100
From:	Robert Shearman <rshearma@...cade.com>
To:	roopa <roopa@...ulusnetworks.com>
CC:	<ebiederm@...ssion.com>, <tgraf@...g.ch>, <davem@...emloft.net>,
	<netdev@...r.kernel.org>
Subject: Re: [PATCH net-next RFC v2 1/3] lwt: infrastructure to support light
 weight tunnels

n 19/06/15 16:14, roopa wrote:
> On 6/19/15, 7:43 AM, Robert Shearman wrote:
>>>
>>> +
>>> +static inline struct lwtunnel_state *lwtunnel_skb_lwstate(struct
>>> sk_buff *skb)
>>> +{
>>> +    struct rtable *rt = (struct rtable *)skb_dst(skb);
>>> +
>>> +    return rt->rt_lwtstate;
>>> +}
>>
>> It doesn't look like this patch will build on its own because
>> rt_lwtstate isn't added to struct rtable until patch 2.
> looks like i messed up the patch creation. I will fix that with the next
> series.
>>
>> More importantly, is it safe to assume that skb_dst will always return
>> an IPv4 dst? How will this look when IPv6 support is added?
>
> Today lwtunnel_skb_lwstate is called from lwtunnel_output which is only
> called from ipv4 code.
> And my ipv6 variant code was supposed to have a 6 suffix. something like
> lwtunnel_output6.
> Or to be more explicit i will probably have variants of the output and
> skb handling functions like,
> lwtunnel_output_ipv4 and lwtunnel_output_ipv6.

Do you intend for these functions to be used by netdevices to support 
the vxlan use case?

If so, then how will the netdevice know which one of the two to call? 
Will there have to be a netdevice for ipv4 and a netdevice for ipv6?

If not, could you outline how you intend for it to be implemented?

Thanks,
Rob
--
To unsubscribe from this list: send the line "unsubscribe netdev" in