On Sun, Feb 5, 2017 at 11:24 AM, David Ahern <d...@cumulusnetworks.com> wrote:
> On 2/3/17 8:34 PM, Alexei Starovoitov wrote:
>> Therefore introduce 'u64 bpf_sk_netns_id(sk);' helper. It returns
>> unique value that identifies netns of given socket or dev_net(skb->dev)
>> The upper 32-bits of the return value contain device id where namespace
>> filesystem resides and lower 32-bits contain inode number within that
>> filesystem.
>> It's the same as
>> struct stat st;
>> stat("/proc/pid/ns/net", &st);
>> return (st->st_dev << 32) | st->st_ino;
>>
> ...
>
>> can be considered a new feature, whereas for cgroup_sock
>> programs that modify sk->bound_dev_if (like 'ip vrf' does)
>> it's a bug fix, since 'ip vrf' needs to be netns aware.
>>
>
>
> LGTM.
>
> Reviewed-by: David Ahern <d...@cumulusnetworks.com>
> Tested-by: David Ahern <d...@cumulusnetworks.com>
>
> Updated patches for vrf in network namespaces are here:
> https://github.com/dsahern/iproute2 vrf/ip-vrf
>
>
> root@kenny-jessie2:~# ip vrf exec red bash
>
> root@kenny-jessie2:red:~# ping -c1 -w1 10.100.1.254
> PING 10.100.1.254 (10.100.1.254) 56(84) bytes of data.
> 64 bytes from 10.100.1.254: icmp_seq=1 ttl=64 time=0.230 ms
>
> --- 10.100.1.254 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.230/0.230/0.230/0.000 ms
>
> root@kenny-jessie2:red:~# unshare -n
>
> root@kenny-jessie2:red:~# ping -c1 -w1 10.100.1.254
> connect: Network is unreachable
>
>
> Andy: thank you for the feedback on the 'ip vrf' use case. I believe this
> kernel patch + my iproute2 patches address the issues mentioned so far.
> Specifically, the transcript above shows your concern about 'unshare -n' case
> is handled. In one of the many responses last night, you mentioned I have 'a
> somewhat kludgey fix that gets the "ip netns" case'. If you can elaborate on
> 'somewhat kludgey', I can fix those this week as well.
What I meant was: fixing it in iproute2 without kernel changes would
be kludgey and incomplete. You seem to have fixed it by depending on
this kernel patch.
--Andy
