[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110429135108.GB2697@psychotron>
Date: Fri, 29 Apr 2011 15:51:09 +0200
From: Jiri Pirko <jpirko@...hat.com>
To: David Miller <davem@...emloft.net>
Cc: mirqus@...il.com, netdev@...r.kernel.org, xemul@...nvz.org
Subject: Re: [PATCH net-next-2.6] veth: remove unneeded ifname code from
veth_newlink()
Thu, Apr 28, 2011 at 10:27:24PM CEST, davem@...emloft.net wrote:
>From: Michał Mirosław <mirqus@...il.com>
>Date: Fri, 22 Apr 2011 11:49:40 +0200
>
>> W dniu 22 kwietnia 2011 11:43 użytkownik Michał Mirosław
>> <mirqus@...il.com> napisał:
>>> 2011/1/24 Jiri Pirko <jpirko@...hat.com>:
>>>> The code is not needed because tb[IFLA_IFNAME] is already
>>>> processed in rtnl_newlink(). Remove this redundancy.
>>> Hi. This patch broke creation of veth devices. Reverting it fixes the issue.
>>>
>>> Symptoms:
>>>
>>> icybox:~# ip link add type veth
>>> RTNETLINK answers: File exists
>>> icybox:~# ip link add type veth peer veth1
>>> icybox:~# ip addr
>>> [...]
>>> 56: D: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>> link/ether e6:57:58:52:03:50 brd ff:ff:ff:ff:ff:ff
>>> 57: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>> link/ether c2:c2:a2:d5:d5:3a brd ff:ff:ff:ff:ff:ff
>>
>> Hmm. I was too quick. Reverting it fixes only first problem - "ip link
>> add type veth" adds new veth pair now, but "ip link add type veth peer
>> veth1" gives the same result as above.
>
>Jiri please look into this regression.
Working on this. Will post patch soon.
Jirka
--
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
Powered by blists - more mailing lists