From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Haller 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 Message-ID: <7153fa4339ebe04d7c3819a8d8eabd789c93753a.camel@redhat.com> References: <51722660f2ef860779e227541dab77046496f135.1535712096.git.lorenzo.bianconi@redhat.com> <1321a4ad-75c5-358f-3a5d-1ec1549a9474@gmail.com> <20180831161902.GD6236@localhost.localdomain> <20180831165444.GE6236@localhost.localdomain> <247de7c5-5046-81f4-d0b9-f6fcd505e8e8@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-0raXNyOz/s7lf/CryPv9" Cc: "David S. Miller" , Network Development To: David Ahern , Lorenzo Bianconi Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:57420 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725898AbeICNaG (ORCPT ); Mon, 3 Sep 2018 09:30:06 -0400 In-Reply-To: <247de7c5-5046-81f4-d0b9-f6fcd505e8e8@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: --=-0raXNyOz/s7lf/CryPv9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Sat, 2018-09-01 at 17:45 -0600, David Ahern wrote: > On 9/1/18 3:05 AM, Lorenzo Bianconi wrote: > >=20 > > 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. >=20 > 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: mtu 1500 qdisc noop = state DOWN group default=20 # link/ether 86:79:1d:c6:45:bc brd ff:ff:ff:ff:ff:ff new-netnsid 0 new-i= findex 9 ip -n ns2 link set veth1 netns ns3 # no event. >>>>>>>>>>>>>>>>>>>>>> best, Thomas --=-0raXNyOz/s7lf/CryPv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEESep8Zw4IUOdBlRT2KcI2bk38VygFAluM+pMACgkQKcI2bk38 VyjEeA//e2dg8+GGFae1Wj8GOigm6ZyJXsl8jfDkGqV0pjRICNeHafPByQafgl6U EbpBKgVFsqgya1QrMa31Uz9PNuh7UrOm6IRlOVlKKQKcg3kON+OwMRpXVywpJF2T Hoz2vZlCebzwU4ldb2OrB+dqGo5JbhGR/k91Xsi0VES/E0MVrjhm19kOCQwHYceT b2WBAVY2goG7ox4D7QqkFEYQLfyA7Z1vUWe4yKp6dTbnGkTTzVmoDs0rGb+AeVQX 9ENsApHmiFylTSq5B59vk03nK19Y/leWKtSKCbh6Wx79CAlLWKXnNlW/2jigT0nf qxqYKeg7aUuX8JmxjlKaatWSozqFb+0FtBKj0knZAPrUyqH88FjEoyvF7hiW9BxK kysxOWyixGXJAt5s7pvut7cohHzIDMCcBRW7mxU7BtW66g3gudAMJ9UP48uRgtDc YLBms8f3jrGT/1xe8gzpm/hr+fLXTOav1g1WkqtJx2yDG2UuKgz4sLlE9vRdu4a2 CWyoQHcuKekeVLx0wVsy2Tgpo4OBBmEgTdEQMet2EQ7dNKEOUrPag/0+qKTIAqKC xY4QZh7BljHlOjsaQ5v2SyW5xIXYaUTfFyQLQk4v1BunKhOrJKNsQMXEGOsk6g6D 86hqb2FFPU5WqNHS3Lh4Gyyr3nMXiIUIwZxGw17NInpemqP2omY= =olPY -----END PGP SIGNATURE----- --=-0raXNyOz/s7lf/CryPv9--