netdev - Re: [RFC PATCH 25/29] net: vrf: Handle VRF any context

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54D41786.6060507@gmail.com>
Date:	Thu, 05 Feb 2015 18:23:18 -0700
From:	David Ahern <dsahern@...il.com>
To:	nicolas.dichtel@...nd.com, netdev@...r.kernel.org
CC:	ebiederm@...ssion.com
Subject: Re: [RFC PATCH 25/29] net: vrf: Handle VRF any context

On 2/5/15 6:46 AM, Nicolas Dichtel wrote:
> Le 05/02/2015 02:34, David Ahern a écrit :
>> VRF any context applies only to tasks to and sockets. Devices are
>> associated with a single VRF, and skb's by extension are connected to
>> a single VRF.
>>
>> Listen sockets and unconnected sockets can be opened in a "VRF any"
>> context allowing a single daemon to provide service across all VRFs
>> in a namespace. Connected sockets must be in a specific vrf context.
>> Accepted sockets acquire the VRF context from the device the packet
>> enters (via the skb).
>>
>> "VRF any" context is also useful for tasks wanting to view L3/L4
>> data for all VRFs.
>>
>> Signed-off-by: David Ahern <dsahern@...il.com>
>> ---
> [snip]
>> +static inline int neigh_parms_net_ctx_eq_any(const struct neigh_parms
>> *parms,
>> +                         const struct net_ctx *net_ctx)
>> +{
>> +#ifdef CONFIG_NET_NS
>> +    if (net_eq(neigh_parms_net(parms), net_ctx->net) &&
>> +        (vrf_eq(neigh_parms_vrf(parms), net_ctx->vrf) ||
>> +         vrf_is_any(net_ctx->vrf))) {
>> +        return 1;
>> +    }
>> +
>> +    return 0;
>> +#else
>> +    return 1;
>> +#endif
> If I understand well, the way the patch is done, VRF can be used only if
> CONFIG_NET_NS is enabled.
> But if I'm not wrong, it could be independent. Am I right?
>

Yes. VRF can exist without namespace. It became tedious to keep tracking 
the CONFIG_NET_NS for the RFC set. Would certainly do that for later 
versions.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html