Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Reply-To: nicolas.dichtel@6wind.com
Subject: Re: [PATCH net-next 0/3 V1] rtnetlink: enable IFLA_IF_NETNSID for
 RTM_{DEL,SET}LINK
References: <20180124142634.17766-1-christian.brauner@ubuntu.com>
 <a0fe573b-c601-9ffc-1f96-0e5f5da86288@6wind.com>
 <20180124173515.5ae2bc05@redhat.com>
 <b8b4a8e3-b574-cc9c-98d1-39911625ad37@6wind.com>
 <20180125233043.66ff08c2@redhat.com>
 <3b916ec7-3aca-13a7-7a48-7a7e8822e488@6wind.com>
 <20180126093629.142e2a74@redhat.com>
To:     Jiri Benc <jbenc@redhat.com>
Cc:     Christian Brauner <christianvanbrauner@gmail.com>,
        netdev@vger.kernel.org, ebiederm@xmission.com, davem@davemloft.net,
        dsahern@gmail.com, fw@strlen.de, daniel@iogearbox.net,
        lucien.xin@gmail.com, mschiffer@universe-factory.net,
        jakub.kicinski@netronome.com, vyasevich@gmail.com,
        linux-kernel@vger.kernel.org, w.bumiller@proxmox.com,
        Christian Brauner <christian.brauner@ubuntu.com>
From:   Nicolas Dichtel <nicolas.dichtel@6wind.com>
Organization: 6WIND
Message-ID: <011a90c5-03a6-14da-d12c-d3ef4316e756@6wind.com>
Date:   Fri, 26 Jan 2018 10:28:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180126093629.142e2a74@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: fr
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Le 26/01/2018 à 09:36, Jiri Benc a écrit :
> On Fri, 26 Jan 2018 00:34:51 +0100, Nicolas Dichtel wrote:
>> Why meaningful? The user knows that the answer is like if if was done in another
>> netns. It enables to have only one netlink socket instead of one per netns. But
>> the code using it will be the same.  
> 
> Because you can't use it to query the linked interface. You can't even
> use it as an opaque value to track interfaces (netnsid+ifindex) because
> netnsids are not unique across net name spaces. You can easily have two
> interfaces that have all the ifindex, ifname, netnsid (and basically
> everything else) identical but being completely different interfaces.
Yes, the user have to map those info correctly. And this complexifies the (user)
code a lot.

> That's really not helpful.
> 
>> I fear that with your approach, it will results to a lot of complexity in the
>> kernel.  
> 
> The complexity is (at least partly) already there. It's an inevitable
> result of the design decision to have relative identifiers.
Yes, you're right. My approach moves the complexity to the user, which make this
feature hard to use.

> 
> I agree that we should think about how to make this easy to implement.
> I like your idea of doing this somehow generically. Perhaps it's
> possible to do while keeping the netnsids valid in the caller's netns?
Yes. I agree that it will be a lot easier to use if the conversion is done in
the kernel. And having a generic mechanism will also help a lot to use it.

> 
>> What is really missing for me, is a way to get a fd from an nsid. The user
>> should be able to call RTM_GETNSID with an fd and a nsid and the kernel performs
>> the needed operations so that the fd points to the corresponding netns.  
> 
> That's what I was missing, too. I even looked into implementing it. But
> opening a fd on behalf of the process and returning it over netlink is a
> wrong thing to do. Netlink messages can get lost. Then you have a fd
> leak you can do nothing about.
Yes, I also looked at this ;-)

> 
> Given that we have netnsids used for so much stuff already (like
> NETLINK_LISTEN_ALL_NSID) you need to track them anyway. And if you need
> to track them, why bother with another identifier? It would be better
> if netnsid can be used universally for anything. Then there will be no
> need for the conversion.
I like this idea a lot. So the missing part is a setns() using the nsid ;-)


Regards,
Nicolas