All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Haller <thaller@redhat.com>
To: David Ahern <dsahern@gmail.com>,
	Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] veth: report NEWLINK event when moving the peer device in a new namespace
Date: Mon, 03 Sep 2018 11:10:43 +0200	[thread overview]
Message-ID: <7153fa4339ebe04d7c3819a8d8eabd789c93753a.camel@redhat.com> (raw)
In-Reply-To: <247de7c5-5046-81f4-d0b9-f6fcd505e8e8@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2516 bytes --]

Hi,

On Sat, 2018-09-01 at 17:45 -0600, David Ahern wrote:
> On 9/1/18 3:05 AM, Lorenzo Bianconi wrote:
> > 
> > I was thinking about the commit 38e01b30563a and then I realized I
> > misread the code
> > yesterday. The commit 38e01b30563a provides all relevant info but
> > it
> > emits the event
> > for veth1 (the device moved in the new namespace).
> > An userspace application will not receive that message if it
> > filters
> > events for just
> > a specific device (veth0 in this case) despite that some device
> > properties have changed
> > (since veth0 and veth1 are paired devices). To fix that behavior in
> > veth_notify routine
> > I emits a RTM_NEWLINK event for veth0.
> 
> Userspace is managing a veth a pair. It moves one of them to a new
> namespace and decides to filter messages related to that device
> before
> the move. If it did not filter the DELLINK message it would get the
> information you want. That to me is a userspace problem. What am I
> missing?

The userspace component which moves the veth peer is likely not the
same that is listening to these events.

> Fundamentally, your proposal means 3 messages when moving a device to
> a
> new namespace which is what I think is unnecessary.

You are correct, the necessary information is signaled in this case.

Usually, one can manage the information about one link by considering
only RTM_NEWLINK/RTM_DELLINK message for that link. That seems
desirable behavior of the netlink API, as it simplifies user space
implementations.

For example, libnl3's cache for links doesn't properly handles this,
and you end up with invalid data in the cache. You may call that a
userspace problem and bug. But does it really need to be that
complicated?

FWIW, a similar thing was also NACK'ed earlier:
  http://lists.openwall.net/netdev/2016/06/12/8



Paolo and Lorenzo pointed out another issue when moving the peer to a
third namespace:

>>>>>>>>>>>>>>>>>>>>>>>>>>>

ip netns del ns1
ip netns del ns2
ip netns del ns3
ip netns add ns1
ip netns add ns2
ip netns add ns3


ip -n ns1 link add dev veth0 type veth peer name veth1
ip -n ns1 monitor link &

ip -n ns1 link set veth1 netns ns2
# Deleted 9: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default 
#    link/ether 86:79:1d:c6:45:bc brd ff:ff:ff:ff:ff:ff new-netnsid 0 new-ifindex 9

ip -n ns2 link set veth1 netns ns3
# no event.

>>>>>>>>>>>>>>>>>>>>>>





best,
Thomas

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-09-03 13:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1535712096.git.lorenzo.bianconi@redhat.com>
2018-08-31 11:43 ` [PATCH net-next] veth: report NEWLINK event when moving the peer device in a new namespace Lorenzo Bianconi
2018-08-31 15:24   ` David Ahern
2018-08-31 16:19     ` Lorenzo Bianconi
2018-08-31 16:21       ` David Ahern
2018-08-31 16:54         ` Lorenzo Bianconi
2018-09-01  9:05           ` Lorenzo Bianconi
2018-09-01 23:45             ` David Ahern
2018-09-03  9:10               ` Thomas Haller [this message]
2018-09-04  2:54                 ` David Ahern
2018-09-07 18:52                   ` Thomas Haller
2018-09-09  1:16                     ` David Ahern

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=7153fa4339ebe04d7c3819a8d8eabd789c93753a.camel@redhat.com \
    --to=thaller@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=lorenzo.bianconi@redhat.com \
    --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.