From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f195.google.com (mail-wr0-f195.google.com [209.85.128.195]) by dpdk.org (Postfix) with ESMTP id 153402C5 for ; Tue, 17 Apr 2018 17:54:02 +0200 (CEST) Received: by mail-wr0-f195.google.com with SMTP id l49so36914321wrl.4 for ; Tue, 17 Apr 2018 08:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ys+Yd1+eab4RMzJz20t/U5JyTMbScHr0VsOxVsZHvDg=; b=tyrJOtkRBjF+2zxbotK6KlcUoSmWqaWnf/BpBGGRHFCrP2OUYrPhEENrONOIG0uSXa rfljxIBPfE09/ez09IxIYdOXwRmtz7XzxuCavY448S7ludjtv7IFIipB0XP1qg35D73r g1eu0LwySL7FMKPB2Y6zNsITiVVobkA3OyLmdlwfgSbnLBWL3GvAoueIgw1WlVKUg50x WfQeZqp5px8zLyL8NeGLKF8qDIbrbqF2YHMCotRys0NEe8KVDewCgHF4LAjFBd3cB2J0 pA4PbqA2oKuWj/ldF7mfYavJONY/qMIeKOYWXKPMMBVU8ur6S8dJJ6DJfykdqgaRdmBr vLQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ys+Yd1+eab4RMzJz20t/U5JyTMbScHr0VsOxVsZHvDg=; b=bu8kwVpS8Ik37IFKfJiUGNxL20XIoozUcuHFYmvdjIKQEjVFUBlCdYvRlP40Zx8oBB uABF9LPwcWStx20x6uUYMNiOw9LaXrbdvpzCOx3S8g+3FC90yEjJ3sSzRYsy5VpI0uzJ imSwOQDBgu7iAWSBT4oLLEsJwtO2inzSm37LljOZq6TuuMQA2fG0MvHO5hsGUYO1MEMT p6AbmAnOZ8NU2UFoZWGLwDPWalMeApT64Dqcbs3X6WI/Lx5A2e0nm2MgqECTDBhIMYep yw04vi1ajFNFNb1vyGM8rlnLUVInkjGtGX03/C0TEouGEu3NhpKqjaCLfNowAqhw4fkn bttg== X-Gm-Message-State: ALQs6tD/tRHUMsJMYceyuRU4rFHvbKg0AQSLBpYlB71a0j2qkKXlvaaG cnuOFao2jI3wnYgz51Gyb13ycWHrOMcIFqjyYw65DA== X-Google-Smtp-Source: AIpwx49nUH0FQW1iw59a2+jyznxlbx8RPgAioEshirGeY2IQCKIlr/sSWQoRg7MqWr1c9dntGhgBiBegZ8YtVDrBMIA= X-Received: by 10.80.234.132 with SMTP id d4mr3759072edo.97.1523980441834; Tue, 17 Apr 2018 08:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.212.197 with HTTP; Tue, 17 Apr 2018 08:54:01 -0700 (PDT) In-Reply-To: References: <20180412222208.11770-1-aconole@redhat.com> <20180412222208.11770-3-aconole@redhat.com> From: Alejandro Lucero Date: Tue, 17 Apr 2018 16:54:01 +0100 Message-ID: To: Aaron Conole Cc: dev , Adrien Mazarguil , stable@dpdk.org, Thomas Monjalon Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC 2/2] nfp: allow for non-root user X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 15:54:02 -0000 I was just wondering, if device device PCI sysfs resource files or VFIO group /dev files require to change permissions for non-root users, does it not make sense to adjust also /var/lock in the system? On Tue, Apr 17, 2018 at 4:44 PM, Alejandro Lucero < alejandro.lucero@netronome.com> wrote: > I have seen that VFIO also requires explicitly to set the right > permissions for non-root users to VFIO groups under /dev/vfio. > > I assume then that running OVS or other DPDK apps as non-root is possible, > although requiring those explicit permissions changes, and therefore this > patch is necessary. > > Adding stable@ and Thomas for discussing how can this be added to stable > DPDK versions even if this is not going to be a patch for current DPDK > version. > > Acked-by: Alejandro Lucero > > > On Fri, Apr 13, 2018 at 4:31 PM, Alejandro Lucero < > alejandro.lucero@netronome.com> wrote: > >> >> >> On Fri, Apr 13, 2018 at 2:31 PM, Aaron Conole wrote: >> >>> Alejandro Lucero writes: >>> >>> > Again, this patch is correct, but because NFP PMD needs to access >>> > /sys/bus/pci/devices/$DEVICE_PCI_STRING/resource$RESOURCE_ID, and >>> these files have just >>> > read/write accesses for root, I do not know if this is really >>> necessary. >>> > >>> > Being honest, I have not used a DPDK app with NFP PMD and not being >>> root. Does it work >>> > with non-root users and other PMDs with same requirements regarding >>> sysfs resource files? >>> >>> We do run as non-root user definitely with Intel PMDs. >>> >>> I'm not very sure about other vendors, but I think mlx pmd runs as >>> non-root user (and it was modified to move off of sysfs for that >>> reason[1]). >>> >>> >> It is possible to not rely on sysfs resource files if device is attached >> to VFIO, but I think that is a must with UIO. >> >> >> >>> I'll continue to push for more information from the testing side to find >>> out though. >>> >>> [1]: http://dpdk.org/ml/archives/dev/2018-February/090586.html >>> >>> > On Fri, Apr 13, 2018 at 12:22 AM, Aaron Conole >>> wrote: >>> > >>> > Currently, the nfp lock files are taken from the global lock file >>> > location, which will work when the user is running as root. However, >>> > some distributions and applications (notably ovs 2.8+ on RHEL/Fedora) >>> > run as a non-root user. >>> > >>> > Signed-off-by: Aaron Conole >>> > --- >>> > drivers/net/nfp/nfp_nfpu.c | 23 ++++++++++++++++++----- >>> > 1 file changed, 18 insertions(+), 5 deletions(-) >>> > >>> > diff --git a/drivers/net/nfp/nfp_nfpu.c b/drivers/net/nfp/nfp_nfpu.c >>> > index 2ed985ff4..ae2e07220 100644 >>> > --- a/drivers/net/nfp/nfp_nfpu.c >>> > +++ b/drivers/net/nfp/nfp_nfpu.c >>> > @@ -18,6 +18,22 @@ >>> > #define NFP_CFG_EXP_BAR 7 >>> > >>> > #define NFP_CFG_EXP_BAR_CFG_BASE 0x30000 >>> > +#define NFP_LOCKFILE_PATH_FMT "%s/nfp%d" >>> > + >>> > +/* get nfp lock file path (/var/lock if root, $HOME otherwise) */ >>> > +static void >>> > +nspu_get_lockfile_path(char *buffer, int bufsz, nfpu_desc_t *desc) >>> > +{ >>> > + const char *dir = "/var/lock"; >>> > + const char *home_dir = getenv("HOME"); >>> > + >>> > + if (getuid() != 0 && home_dir != NULL) >>> > + dir = home_dir; >>> > + >>> > + /* use current prefix as file path */ >>> > + snprintf(buffer, bufsz, NFP_LOCKFILE_PATH_FMT, dir, >>> > + desc->nfp); >>> > +} >>> > >>> > /* There could be other NFP userspace tools using the NSP interface. >>> > * Make sure there is no other process using it and locking the >>> access for >>> > @@ -30,9 +46,7 @@ nspv_aquire_process_lock(nfpu_desc_t *desc) >>> > struct flock lock; >>> > char lockname[30]; >>> > >>> > - memset(&lock, 0, sizeof(lock)); >>> > - >>> > - snprintf(lockname, sizeof(lockname), "/var/lock/nfp%d", >>> desc->nfp); >>> > + nspu_get_lockfile_path(lockname, sizeof(lockname), desc); >>> > >>> > /* Using S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | >>> S_IWOTH */ >>> > desc->lock = open(lockname, O_RDWR | O_CREAT, 0666); >>> > @@ -106,7 +120,6 @@ nfpu_close(nfpu_desc_t *desc) >>> > rte_free(desc->nspu); >>> > close(desc->lock); >>> > >>> > - snprintf(lockname, sizeof(lockname), "/var/lock/nfp%d", >>> desc->nfp); >>> > - unlink(lockname); >>> > + nspu_get_lockfile_path(lockname, sizeof(lockname), desc); >>> > return 0; >>> > } >>> > -- >>> > 2.14.3 >>> >> >> >