Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1381685imm; Sun, 2 Sep 2018 21:40:00 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZ627ASNfkedn8zznSYSpRJLISdIMH0oMLuVkeVpBTBXac5I2zBQQNbPc2kFW3dSsWSTA9G X-Received: by 2002:a63:fe4d:: with SMTP id x13-v6mr24805699pgj.152.1535949600368; Sun, 02 Sep 2018 21:40:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535949600; cv=none; d=google.com; s=arc-20160816; b=0W7psuiNjwp6H3jjACdrXZ49IT136C9nzqoFtYmZX1f65cvgh61AA6Fpae8uwU+m7g RdF9mPpOSL+GJVr0/osng2MNcuNv50UnNKdBwnPR9LyxbGVC3ycgBSrwFPWDnEU2iyVB FtxO4/kQdgZcqRrC3W5WVplGcTKe/iS5zRdmFgcl+1yjXJ3+jMHkL4RI+cmai5THbsv5 yVa1ayWsU+n/hy9/oUL/wTsE3ZJDITJgGF/CWjD8YY9SubOJsYqeoyzbjWIaspjQaW9x 8irEs6WytscBpb+iIWGulvmFyBnr0PuL+aFcYKedEP/3DRHSVwsCW9hKdeEbUoujNBvU UfYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=yjW5BnLnD8Pl4Pzcea+N4HMJEVQUQmk2YMUHH+3N+24=; b=RNJm6rUhXaS50QgSZEsRjgMNGgjmeGWULjHj+0FE+ml9FbAOtMuRM7jctm7sdKJvxV Q74yHextsHn3GQkOAvOovTfw0O//aqASZgJjr2qyqHN+Z17fYdwGw1RJtWqnO97QHLit V4pwnPF8Op+3vUaZgsm6Pk2fljDYxvTGVVBXMzxadlWBn6yNtqco7KmIdSln9Vk+TGFg /F+XueQNWkoq2EmvmKTlc8JiMjaXsp5q4ht0wRp2+UgJqiGDjlzkGyS9qAMoGkh2J2yp 4k50MNPWiFACnQlKMXF34NQQx+rATMN8yvfsrE2VNSs9XZV2h58d5HYtYUJCDAvN47PT 9DpQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y20-v6si14605983plr.110.2018.09.02.21.39.45; Sun, 02 Sep 2018 21:40:00 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726160AbeICI5F (ORCPT + 99 others); Mon, 3 Sep 2018 04:57:05 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36369 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725892AbeICI5E (ORCPT ); Mon, 3 Sep 2018 04:57:04 -0400 Received: by mail-wm0-f66.google.com with SMTP id j192-v6so10326507wmj.1; Sun, 02 Sep 2018 21:38:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=yjW5BnLnD8Pl4Pzcea+N4HMJEVQUQmk2YMUHH+3N+24=; b=dULs5gh6wTsQdgqSk6RyT4ZD8IoQfx+ovYCNREHNFEQs5aXuvRymHzUjhbH89E1FNA aacovp9WZM/b0XNih5MgwFJwpsfTIu8LcSkbVM4emHIF94Ic/dmLTyG9xHGYL1bZkq+2 QD3i0sO1epj4S5NsZltubbVe8I9/drLb0hRt+P8utpTucIId7JTAcpp7XDiLGqxC3GFW 5Thb/Yi3YiP8PYk0QFg5Lp4OTJBhTu+7pX2hJwCplbuQNYPbv26lCI8Be646qkIL5Dfd 5sUVhNN1avKEver7bzXpMNL01NQ5qsTUt6qXNkefO4CoQTl77FZ+NKEfCy7AARXPds6E E/dA== X-Gm-Message-State: APzg51ChTgPfYsAE6C8qj1cb5Et0I2bZZu7edb14gdGqPvKLBTF7JP3K 30xTYdDQYH94fcnuMK8CfvmiEHuUrVg= X-Received: by 2002:a1c:1c92:: with SMTP id c140-v6mr3714899wmc.155.1535949518842; Sun, 02 Sep 2018 21:38:38 -0700 (PDT) Received: from localhost.localdomain ([88.128.81.0]) by smtp.gmail.com with ESMTPSA id j66-v6sm22453364wrj.28.2018.09.02.21.38.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Sep 2018 21:38:37 -0700 (PDT) From: Christian Brauner To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, pombredanne@nexb.com, kstewart@linuxfoundation.org, gregkh@linuxfoundation.org, dsahern@gmail.com, fw@strlen.de, ktkhai@virtuozzo.com, lucien.xin@gmail.com, jakub.kicinski@netronome.com, jbenc@redhat.com, nicolas.dichtel@6wind.com, Christian Brauner Subject: [PATCH net-next v1 0/5] rtnetlink: add IFA_IF_NETNSID for RTM_GETADDR Date: Mon, 3 Sep 2018 06:37:12 +0200 Message-Id: <20180903043717.20136-1-christian@brauner.io> X-Mailer: git-send-email 2.17.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey, # v1 introduction: The only functional change is the export of rtnl_get_net_ns_capable() which is needed in case ipv6 is built as a module. Note, I did not change the property name to IFA_TARGET_NSID as there was no clear agreement what would be preferred. My personal preference is to keep the IFA_IF_NETNSID name because it aligns naturally with the IFLA_IF_NETNSID property for RTM_*LINK requests. Jiri seems to prefer this name too. However, if there is agreement that another property name makes more sense I'm happy to send a v2 that changes this. ## Performance: To test this patchset I performed 1 million getifaddrs() requests against a network namespace containing 5 interfaces (lo, eth{0-4}). The first test used a network namespace aware getifaddrs() implementation I wrote and the second test used the traditional setns() + getifaddrs() method. The results show that this patchsets allows userspace to cut retrieval time in half: 1. netns_getifaddrs(): 82 microseconds 2. setns() + getifaddrs(): 162 microseconds # v0 introduction: A while back we introduced and enabled IFLA_IF_NETNSID in RTM_{DEL,GET,NEW}LINK requests (cf. [1], [2], [3], [4], [5]). This has led to signficant performance increases since it allows userspace to avoid taking the hit of a setns(netns_fd, CLONE_NEWNET), then getting the interfaces from the netns associated with the netns_fd. Especially when a lot of network namespaces are in use, using setns() becomes increasingly problematic when performance matters. Usually, RTML_GETLINK requests are followed by RTM_GETADDR requests (cf. getifaddrs() style functions and friends). But currently, RTM_GETADDR requests do not support a similar property like IFLA_IF_NETNSID for RTM_*LINK requests. This is problematic since userspace can retrieve interfaces from another network namespace by sending a IFLA_IF_NETNSID property along but RTM_GETLINK request but is still forced to use the legacy setns() style of retrieving interfaces in RTM_GETADDR requests. The goal of this series is to make it possible to perform RTM_GETADDR requests on different network namespaces. To this end a new IFA_IF_NETNSID property for RTM_*ADDR requests is introduced. It can be used to send a network namespace identifier along in RTM_*ADDR requests. The network namespace identifier will be used to retrieve the target network namespace in which the request is supposed to be fulfilled. This aligns the behavior of RTM_*ADDR requests with the behavior of RTM_*LINK requests. ## Security: - The caller must have assigned a valid network namespace identifier for the target network namespace. - The caller must have CAP_NET_ADMIN in the owning user namespace of the target network namespace. Thanks! Christian [1]: commit 7973bfd8758d ("rtnetlink: remove check for IFLA_IF_NETNSID") [2]: commit 5bb8ed075428 ("rtnetlink: enable IFLA_IF_NETNSID for RTM_NEWLINK") [3]: commit b61ad68a9fe8 ("rtnetlink: enable IFLA_IF_NETNSID for RTM_DELLINK") [4]: commit c310bfcb6e1b ("rtnetlink: enable IFLA_IF_NETNSID for RTM_SETLINK") [5]: commit 7c4f63ba8243 ("rtnetlink: enable IFLA_IF_NETNSID in do_setlink()") Christian Brauner (5): rtnetlink: add rtnl_get_net_ns_capable() if_addr: add IFA_IF_NETNSID ipv4: enable IFA_IF_NETNSID for RTM_GETADDR ipv6: enable IFA_IF_NETNSID for RTM_GETADDR rtnetlink: move type calculation out of loop include/net/rtnetlink.h | 1 + include/uapi/linux/if_addr.h | 1 + net/core/rtnetlink.c | 19 +++++++--- net/ipv4/devinet.c | 38 +++++++++++++++----- net/ipv6/addrconf.c | 70 ++++++++++++++++++++++++++++-------- 5 files changed, 101 insertions(+), 28 deletions(-) -- 2.17.1