All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: netdev@vger.kernel.org
Subject: Re: network namespace and kernel bind issue
Date: Mon, 01 Oct 2012 16:11:07 -0700	[thread overview]
Message-ID: <87y5jpdbzo.fsf@xmission.com> (raw)
In-Reply-To: <20121001155702.5b5e2188@nehalam.linuxnetplumber.net> (Stephen Hemminger's message of "Mon, 1 Oct 2012 15:57:02 -0700")

Stephen Hemminger <shemminger@vyatta.com> writes:

> On Mon, 01 Oct 2012 15:40:56 -0700
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>
>> Stephen Hemminger <shemminger@vyatta.com> writes:
>> 
>> > On Mon, 1 Oct 2012 14:16:09 -0700
>> > Stephen Hemminger <shemminger@vyatta.com> wrote:
>> >
>> >> When testing VXLAN I noticed that the kernel bind seems to be a problem for
>> >> network tunnels. The init_net function is called repeatedly for the same
>> >> network namespace!
>> 
>> It definitely should not be.
>> 
>> >> 1. Create vxlan device:
>> >>  # ip li add vxlan0 type vxlan id 11 group 239.1.1.1 dev eth0
>> >>  # dmesg | tail
>> >> [11580.671016] vxlan: vxlan_init_net in net 1
>> 
>> Net 1?  What are you printing out?  It isn't the net_id by any chance?
>
> Yes it is the net_id which is passed to net_generic() to find the
> per-namespace data structure.

Yes.  net_id is just an index and is the same in all network namespaces.
net_id should only be different for different instances of per_net
operations.

>> >> 2. Start Chrome (or other application using namespaces)
>> >>  
>> >>   dmesg | tail
>> >> [11587.371195] vxlan: vxlan_init_net in net 1
>> >> [11587.371211] vxlan: bind for UDP socket 0.0.0.0:8472 (-98)
>> >> 
>> >> 
>> >> Isn't init_net supposed to be unique. The current semantics also break
>> >> L2TP.
>> 
>> The init method should be called exactly once per network namespace.
>> 
>> The timing of the init methods you report seems correct.
>> 
>> The vxlan code isn't in net-next or I would take a look.
>> 
>> I took a quick look at l2tp and the code is doing some weird things.
>> There are a bunch of references to &init_net that I would expect
>> to references to either sk_net() or dev_net().  
>> 
>> Adding support for multiple network namespaces and then reaching
>> out to the initial network namespace for things is definitely a recipe
>> for getting confused.
>> 
>> So my blind guess would be that someone half implemented network
>> namespace support for l2tp and vxlan copied the bugs.
>
> The vxlan driver has one UDP socket per namespace.
> There are no references to init_net in it.

Then my guess is that you have an ordering problem.  Attempting
to initialize a vxlan before ipv4 is initialized or some such.

> I think the problem is the call chain
>       copy_net_ns -> setup_net -> ops_init
> There is nothing that nothing increments the id after register_pernet_operations.
>
> Shouldn't there be an increment so each new namespace gets a unique id?

No.

There are some extra pointers at the end of struct net and the id is
which of those pointers your subsystem gets to use.  net_generic returns
your pointer value.

I can see the confusion but the id is definitely not a namespace id.

Eric

  reply	other threads:[~2012-10-01 23:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20121001141609.14639bc0@nehalam.linuxnetplumber.net>
     [not found] ` <20121001145838.5eafef4c@nehalam.linuxnetplumber.net>
2012-10-01 22:40   ` network namespace and kernel bind issue Eric W. Biederman
2012-10-01 22:57     ` Stephen Hemminger
2012-10-01 23:11       ` Eric W. Biederman [this message]
2012-10-01 23:32         ` Stephen Hemminger
2012-10-02  0:35           ` Eric W. Biederman
2012-10-02  0:48             ` Stephen Hemminger
2012-10-02  6:15               ` Julian Anastasov
2012-10-02 15:51                 ` Stephen Hemminger
2012-10-02  0:51             ` [PATCH net-next] vxlan: put UDP socket in correct namespace Stephen Hemminger
2012-10-02  0:58               ` Eric W. Biederman
2012-10-02  4:49                 ` [PATCHv2 " Stephen Hemminger
2012-10-02 15:18                   ` Eric W. Biederman
2012-10-02 18:39                     ` David Miller

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=87y5jpdbzo.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    /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.