Re: new link failing on duplicate names in different namespaces

[ebiederm@xmission.com (Eric W. Biederman)]

Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:

> Le 25/02/2015 01:48, Eugene Yakubovich a écrit :
>> Hello,
>>
>> rtnetlink's RTM_NEWLINK allows for specifying the network namespace in
>> which the link is to be created via IFLA_NET_NS_PID or IFLA_NET_NS_FD.
>> This not only saves a user a call to move the link into the target
>> namespace, it can avoid a potential ifname conflict. For example, if
>> creating eth0 in another namespace and the current one already has
>> eth0.
>>
>> Unfortunately, this is not the current behavior. If the user specifies
>> IFLA_IFNAME, leaves ifinfomsg.ifi_index unspecified and sets
>> NLM_F_EXCL flag, as in the case of creating a new link, the call will
>> fail with EEXIST in cases where there's a name conflict.
>>
>> rtnl_newlink() will:
>>
>> if (ifname[0])
>>      dev = __dev_get_by_name(net, ifname);
> Yes, it seems that this should be done in "dest_net" or "link_net".

Ugh.  Looking at that code I think the link_net is at best extremely
confusing most likely semantically broken the way it is being
interpreted in rtnl_newlink.  More in another email message.

The original semantics and what seems mostly reasonable because the
network device in some sense lives in multiple network namespaces
as it is being created is that the network device name be unique
in both namespaces.

The code that creates a network devices fundamentally needs to know
about both namespaces network devices like the macvlan driver need
to find their lower devices in the original network namespace.

I think we could possibly remove the restriction for the names of newly
created network devices being unique in both network namespaces but I
don't think the code changes will be trivial.

Eric