From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AB972C43381 for ; Fri, 22 Mar 2019 15:44:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6DBCB2183E for ; Fri, 22 Mar 2019 15:44:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="FgckEgve" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727436AbfCVPon (ORCPT ); Fri, 22 Mar 2019 11:44:43 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:37453 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727413AbfCVPom (ORCPT ); Fri, 22 Mar 2019 11:44:42 -0400 Received: by mail-pf1-f194.google.com with SMTP id 8so1803445pfr.4 for ; Fri, 22 Mar 2019 08:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ZYN06bHZGr7lQ4gAZmtGFWqorH5HkDa/hj4vM5u9k8c=; b=FgckEgvefLIB6fQN5RTsy3Vf4KB3rlxZEX6qxv+xkZjsfvApMiSiffewmaN01UjzDi yTtWAWFemDHotgNKQEWoojv8aQVEbwtrGe8LJUPY+iReaSsuhfRuLGk0oFRf3ZEmvti6 v10koHnk9AkBDGtyngdTxrUZxIvxreblaXaek9Nk1lacmNQyJnpLLvBhyrjJj2LsfIxr k8Ieozylgggj4MbbQX3BppmHQk551RbfYxuJ+b8t/ARypnGCd714jLpl7pkALKdqNPwa 24JNpF+0tgX7eGSFs5jwo5uSLFZJ+BgTZwitAK2iftVJ/oJjVKAftwdDHfGTlOoPCXdn 2JoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ZYN06bHZGr7lQ4gAZmtGFWqorH5HkDa/hj4vM5u9k8c=; b=QTP0tiMZbV82uCV90vgZFQJtK7JEYukGUx+jvvk75lrRZ1pEwyLjT3ZbejD2xWpVhP Hk5XaXfq9s7m7s0quADb6p6+YBrMi0faImHRsEGifQ97GBXXD4pMHSy6V4ZNPXc7jsPI oloaZDfAi2SjPkftWK2kVSqeGLmDuvj5QgQc/H6y8pdJBMZVIw/q/Lkjaq7k0tdtZTJG Dn/06oMCJ5dSTgx7JlwHDFBQWP96zIdMiXZAYh4Gi59CrXzpsJDtaVW5G4b1+WDPXJU3 O2UbgIz38st1QszIL7+ycgIvWm1CvtxGyjnBxYZQTb0Ai/N/1y3JutH3J8Jqk7mx9Xzw 2KVw== X-Gm-Message-State: APjAAAV+2SmO7iCMHbvy5555SwE7+DlRbr5PD+acnhDoiDom+XFxn5C3 tfarJXklw8juKKtt7Wx7cx40GQ== X-Google-Smtp-Source: APXvYqwhi8sH4zkLOcUZj1KKoqOQejkAc7/FWtj9Tp/dsnTUpROGQv27smYXKyWxjcaZCJ4kr+rucg== X-Received: by 2002:a17:902:b484:: with SMTP id y4mr2488039plr.88.1553269481693; Fri, 22 Mar 2019 08:44:41 -0700 (PDT) Received: from shemminger-XPS-13-9360 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id g67sm1376224pfg.94.2019.03.22.08.44.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 22 Mar 2019 08:44:41 -0700 (PDT) Date: Fri, 22 Mar 2019 08:44:37 -0700 From: Stephen Hemminger To: "Harald Albrecht" Cc: netdev@vger.kernel.org Subject: Re: [RFC 1/1] net/tun: fdinfo to relate TAP/TUN network interfaces unambiguously with their serving processes Message-ID: <20190322084437.3492fd76@shemminger-XPS-13-9360> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 22 Mar 2019 08:40:17 +0100 "Harald Albrecht" wrote: > This is a first for me to appear on the Linux kernel netdev list, so please bear with me while killing me... > > For diagnosing Linux virtual networking I need to relate TAP/TUN network interfacces to the user space processes they are served by. I'm aware of Kirill Tkhai's TUN SIOCGSKNS ioctl patches. My usecase is that my diagnosis software is a process different from a TAP/TUN serving process, so issuing the ioctl() is not really possible to outside processes (without resorting to gorilla tactics like attaching to the serving process, pausing it, and then injecting ioctl() calls). For my usecase, /proc/$PID/fdinfo/$FD is an easy-to-use source of the information I need for diagnosis. > > At the moment, fdinfo for a TAP/TUN device unfortunately only returns the name of the TAP/TUN network interface the fd is connected to for serving. Unfortunately, this does not allow for unambiguous identification in such system configurations where there are multiple TAP/TUN network interfaces of the same ifname, but in different network namespaces. In addition to the ifname, a network namespace reference is necessary where the TAP/TUN network interface is currently living in. Together, these two nuggets of information allow to unambiguously relate TAP/TUN serving processes with the correct TAP/TUN network interfaces. > > To achieve this, I would like you to give feedback on potential additional information in fdinfo for TAP/TUN, please see the following patch for discussion. I'm also providing a "test" script at https://gist.github.com/TheDiveO/d0834baacc92a7ab25300fd8c7468b61 that creates two identically named TAP/TUN network interfaces, but in different network namespaces, with a dummy serving process living in a third network namespace. This requires a dummy TAP serving process tapclient.c to also to be found here in the same GitHub gist: https://gist.github.com/TheDiveO/d0834baacc92a7ab25300fd8c7468b61. > > About my potential patch: > > - adds two new keys "iffnetns:" and "devnetns:". > > - "iffnetns:" references the network namespace where the TAP/TUN network interface (if created) is located in. The format is the same as if readlink() a network namespace fd, such as in "$readlink /proc/self/ns/net". In particular, the textual representation is "net:[%u]", where %u is the inode number of the specific network namespace. > > - "devnetns:" references the network namespace where the control fd would create new TAP/TUN network interfaces; please note that this can be different from the network namespace where the currently created TAP/TUN network interface is currently located in. Again, this reference is in the same textual format as for the "iffnetns:" key. > > - at the moment I'm at a loss as to whether this additional information needs to be subjected to CAP_NET? > > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index 53f4f37b0ffd..1ddc22b35d0a 100644 > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -3440,22 +3440,37 @@ static int tun_chr_close(struct inode *inode, struct file *file) > #ifdef CONFIG_PROC_FS > static void tun_chr_show_fdinfo(struct seq_file *m, struct file *file) > { > - struct tun_file *tfile = file->private_data; > - struct tun_struct *tun; > - struct ifreq ifr; > - > - memset(&ifr, 0, sizeof(ifr)); > - > - rtnl_lock(); > - tun = tun_get(tfile); > - if (tun) > - tun_get_iff(current->nsproxy->net_ns, tun, &ifr); > - rtnl_unlock(); > - > - if (tun) > - tun_put(tun); > - > - seq_printf(m, "iff:\t%s\n", ifr.ifr_name); > + struct tun_file *tfile = file->private_data; > + struct tun_struct *tun; > + struct ifreq ifr; > + unsigned int iffnetnsinum = 0; /* netns of TAP/TUN nif */ > + unsigned int tnetnsinum = 0; /* netns captured when opening /dev/net/tun */ > + > + memset(&ifr, 0, sizeof(ifr)); > + > + rtnl_lock(); > + tun = tun_get(tfile); > + if (tun) { > + tun_get_iff(current->nsproxy->net_ns, tun, &ifr); > + /* network namespace where this /dev/net/tun char device fd reference > + * will create new TAP/TUN network interfaces. > + */ > + tnetnsinum = sock_net(&tfile->sk)->ns.inum; > + /* network namespace where the TAP/TUN network interface > + * currently is located in. > + */ > + iffnetnsinum = dev_net(tun->dev)->ns.inum; > + } > + rtnl_unlock(); > + > + if (tun) > + tun_put(tun); > + > + seq_printf(m, "iff:\t%s\n", ifr.ifr_name); > + if (iffnetnsinum) > + seq_printf(m, "iffnetns:\tnet:[%u]\n", iffnetnsinum); > + if (tnetnsinum) > + seq_printf(m, "devnetns:\tnet:[%u]\n", tnetnsinum); > } > #endif > > Harald The /proc formats are fixed and legacy at this point. Please don't add anything new. Why not add values to sysfs (one value per file)? Use the kernel checkpatch utility to check for style issues please.