netdev - Re: [PATCH net-next] veth: report NEWLINK event when moving the peer device in a new namespace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8eb1f295bbfe0d662e0df19448e9719be24348f5.camel@redhat.com>
Date:   Fri, 07 Sep 2018 20:52:30 +0200
From:   Thomas Haller <thaller@...hat.com>
To:     David Ahern <dsahern@...il.com>,
        Lorenzo Bianconi <lorenzo.bianconi@...hat.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] veth: report NEWLINK event when moving the
 peer device in a new namespace

Hi David,

On Mon, 2018-09-03 at 20:54 -0600, David Ahern wrote:

> From init_net:
> $ ip monitor all-nsid

I thought the concern of the patch is the overhead of sending one
additional RTM_NEWLINK message. This workaround has likely higher
overhead. More importantly, it's so cumbersome, that I doubt anybody
would implementing such a solution.

When the events of one namespace are not sufficient to get all relevant
information (local to the namespace itself), the solution is not
monitor all-nsid.

You might save complexity and performance overhead in kernel. But what
you save here is just moved to user-space, which faces higher
complexity (at multiple places/projects, where developers are not
experts in netlink) and higher overhead.

RTM_GETLINK/NLM_F_DUMP allows to fetch information. The same
information is usually also emitted on changes via RTM_NEWLINK
notifications.
Yes, the information may be avilable somehow, but how cumbersome:

 a) receive RTM_DELLINK, recognize that the message belongs to a 
   veth that was moved to another netns, and recognize that the peer's 
   IFLA_LINK changed. This approach only works when the veth is moved
   away from the current namespace.
 b) or, enable monitor all-nsid, receive RTM_NEWLINK, recognize that 
   the event is for moving a veth between netns, find the peer in the 
   other netns and recognize that the peer's IFLA_LINK changed.

best,
THomas

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)