From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by dpdk.org (Postfix) with ESMTP id 63C9F1C30C for ; Fri, 13 Apr 2018 15:24:58 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0B51D401DEA7; Fri, 13 Apr 2018 13:24:58 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E3C1920BC8C7; Fri, 13 Apr 2018 13:24:57 +0000 (UTC) From: Aaron Conole To: Alejandro Lucero Cc: dev References: <20180412222208.11770-1-aconole@redhat.com> <20180412222208.11770-2-aconole@redhat.com> Date: Fri, 13 Apr 2018 09:24:57 -0400 In-Reply-To: (Alejandro Lucero's message of "Fri, 13 Apr 2018 09:31:41 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Fri, 13 Apr 2018 13:24:58 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Fri, 13 Apr 2018 13:24:58 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'aconole@redhat.com' RCPT:'' Subject: Re: [dpdk-dev] [RFC 1/2] nfp: unlink the appropriate lock file 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: Fri, 13 Apr 2018 13:24:58 -0000 Alejandro Lucero writes: > Although the patch is correct, the truth is there was not option for locks but "nfp0", because > the PMD did not support more than one NFP card. > > After commit with CPP support, the PMD can support more than one NFP card, but this > interface is not supported anymore and this file was removed. > > is this patch coming from some code revision or from a problem you found? Just a code review - we were reported a problem initializing the driver, and in looking at the lock/unlock code, it seems that it was always releasing the nfp0 lock. Good to know that in practice it likely wouldn't cause real harm. I intend to resubmit this as is. Thanks, Alejandro! > On Fri, Apr 13, 2018 at 12:22 AM, Aaron Conole wrote: > > The nfpu_close needs to unlink the lock file associated with the > nfp descriptor, not lock file 0. > > Fixes: d12206e00590 ("net/nfp: add NSP user space interface") > > Cc: stable@dpdk.org > Signed-off-by: Aaron Conole > --- > drivers/net/nfp/nfp_nfpu.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/nfp/nfp_nfpu.c b/drivers/net/nfp/nfp_nfpu.c > index f11afef35..2ed985ff4 100644 > --- a/drivers/net/nfp/nfp_nfpu.c > +++ b/drivers/net/nfp/nfp_nfpu.c > @@ -101,8 +101,12 @@ nfpu_open(struct rte_pci_device *pci_dev, nfpu_desc_t *desc, > int nfp) > int > nfpu_close(nfpu_desc_t *desc) > { > + char lockname[30]; > + > rte_free(desc->nspu); > close(desc->lock); > - unlink("/var/lock/nfp0"); > + > + snprintf(lockname, sizeof(lockname), "/var/lock/nfp%d", desc->nfp); > + unlink(lockname); > return 0; > } > -- > 2.14.3