All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelianov <xemul@openvz.org>
To: Patrick McHardy <kaber@trash.net>
Cc: David Miller <davem@davemloft.net>,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [PATCH 2/2] Virtual ethernet device driver
Date: Thu, 12 Jul 2007 17:36:42 +0400	[thread overview]
Message-ID: <46962E6A.5020906@openvz.org> (raw)
In-Reply-To: <46962AC5.2030005@trash.net>

Patrick McHardy wrote:
> Pavel Emelianov wrote:
>> Patrick McHardy wrote:
>>
>>> Pavel Emelianov wrote:
>>>
>>>> +static int veth_newlink(struct net_device *dev,
>>>> +			 struct nlattr *tb[], struct nlattr *data[])
>>>> +{
>>>> +	int err;
>>>> +	struct net_device *peer;
>>>> +	struct veth_priv *priv;
>>>> +	char ifname[IFNAMSIZ];
>>>> +
>>>> +	/*
>>>> +	 * prepare the devices info
>>>> +	 */
>>>> +
>>>> +	if (tb[IFLA_ADDRESS] == NULL)
>>>> +		random_ether_addr(dev->dev_addr);
>>>> +
>>>> +	if (data != NULL && data[VETH_INFO_PEER] != NULL) {
>>>> +		err = nla_parse_nested(tb, IFLA_INFO_MAX,
>>>> +				data[VETH_INFO_PEER], ifla_policy);
>>>> +		if (err < 0)
>>>> +			return err;
>>>> +	}
>>>
>>> Not having a peer should be an error, no?
>>
>> No. That's the intention - if the user doesn't specify "peer" in the
>> command line then two _identical_ devices are created. Of course, if
>> he specifies one name - there'll be a collision, but one can say
>> "my_own_veth_number_%d" and everything will be ok. Or just use the 
>> default name provided. E.g. "ip link add type veth" will send a packet
>> with data[VETH_INFO_PEER} == NULL, but this is OK! User just wants a 
>> default tunnel and he will get it :)
> 
> I see.
> 
>> Does this answer your second comment below?
> 
> 
> No, to get unique names the sequence has to be:
> 
> dev_alloc_name
> register_netdevice
> dev_alloc_name
> register_netdevice
> 
> But you have:
> 
> dev_alloc_name
> dev_alloc_name (<- might allocate same name as first call)
> register_netdevice
> register_netdevice

Oops :) You're right. That's the problem. I was carried away by
testing the "peer" options and checking for names rather than
"veth%d" to work...

By the way, that will create some problems. You see, your patches
imply that the register_netdevice() will be called at the very end
of the ->newlink callback. Otherwise, the error path of any code
following the registering will have to call unregister_netdevice()
which will BUG() in free_netdev() in rtnl_newlink() - the device
state will be neither UNINITIALIZED nor UNREGISTERED :(

>>>> +static __exit void veth_exit(void)
>>>> +{
>>>> +	struct veth_priv *priv, *next;
>>>> +
>>>> +	rtnl_lock();
>>>> +	__rtnl_link_unregister(&veth_link_ops);
>>>> +
>>>> +	list_for_each_entry_safe(priv, next, &veth_list, list)
>>>> +		veth_dellink(priv->dev);
>>>> +	rtnl_unlock();
>>>
>>> Devices are unregistered automatically through the dellink function,
>>> rtnl_link_unregister(..) is enough.
>>
>> OK. This looks like a minor and not-significant comment, so
>> do I need to resend the patch or David is OK to take it and
>> I will send an incremental one?
> 
> 
> An incremental patch for this is fine I guess, your code is correct,
> its merely a simplification.
> 

Thanks,
Pavel

  reply	other threads:[~2007-07-12 13:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-12  9:13 [PATCH 0/2] Virtual ethernet device (v3) Pavel Emelianov
2007-07-12  9:17 ` [PATCH 1/2] Introduce the generic rtnl_create_link() Pavel Emelianov
2007-07-12  9:19 ` [PATCH 2/2] Virtual ethernet device driver Pavel Emelianov
2007-07-12 12:31   ` Patrick McHardy
2007-07-12 13:14     ` Pavel Emelianov
2007-07-12 13:21       ` Patrick McHardy
2007-07-12 13:36         ` Pavel Emelianov [this message]
2007-07-12 13:44           ` Patrick McHardy
2007-07-12 13:58             ` Pavel Emelianov
2007-07-12 13:17     ` Pavel Emelianov
2007-07-12 13:24       ` Patrick McHardy
2007-07-16  9:10         ` Pavel Emelianov
2007-07-12 13:51   ` Patrick McHardy
2007-07-12 14:01     ` Pavel Emelianov
2007-07-12 14:10       ` Patrick McHardy
2007-07-16  9:16         ` Pavel Emelianov
2007-07-16 13:13           ` Patrick McHardy
2007-07-12  9:21 ` [PATCH 0/2] Module for ip utility to support veth device (v.3) Pavel Emelianov
2007-07-12  9:23   ` [PATCH 1/2] Intruduce iplink_parse() routine Pavel Emelianov
2007-07-12  9:25   ` [PATCH 2/2] Module for ip utility to support veth device Pavel Emelianov
  -- strict thread matches above, loose matches on Subject: below --
2007-07-19  9:24 [PATCH] Virtual ethernet device (v.4) Pavel Emelyanov
2007-07-19  9:28 ` [PATCH 2/2] Virtual ethernet device driver Pavel Emelyanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46962E6A.5020906@openvz.org \
    --to=xemul@openvz.org \
    --cc=davem@davemloft.net \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.