DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: dev@dpdk.org, thomas@monjalon.net
Subject: Re: [dpdk-dev] [PATCH v3 5/9] mem: fix potential resource leak
Date: Fri, 27 Apr 2018 16:52:12 +0100	[thread overview]
Message-ID: <20180427155212.GB94056@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <c060b499-f40d-eeea-d467-60309395f14c@intel.com>

On Fri, Apr 27, 2018 at 04:49:03PM +0100, Burakov, Anatoly wrote:
> On 27-Apr-18 4:21 PM, Bruce Richardson wrote:
> > On Wed, Apr 25, 2018 at 10:56:43AM +0100, Anatoly Burakov wrote:
> > > Normally, tailq entry should have a valid fd by the time we attempt
> > > to map the segment. However, in case it doesn't, we're leaking fd,
> > > so fix it.
> > > 
> > > Coverity issue: 272570
> > > 
> > > Fixes: 2a04139f66b4 ("eal: add single file segments option")
> > > Cc: anatoly.burakov@intel.com
> > > 
> > > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > > ---
> > >   lib/librte_eal/linuxapp/eal/eal_memalloc.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/lib/librte_eal/linuxapp/eal/eal_memalloc.c b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
> > > index fab5a98..b02e3a5 100644
> > > --- a/lib/librte_eal/linuxapp/eal/eal_memalloc.c
> > > +++ b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
> > > @@ -524,6 +524,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id,
> > >   			if (te != NULL && te->fd >= 0) {
> > >   				close(te->fd);
> > >   				te->fd = -1;
> > 
> > Is "fd" still not being leaked here, since we won't hit the else case and
> > then jump to the end of the function where it goes out of scope?
> 
> Technically, the "else" case is never valid here. If we have a tailq entry -
> we always have a valid fd. So perhaps it should be classified as a false
> positive.
> 
If there is a (non-harmful) way to fix it in the code, I'd definitely thing
we should do so. It means that any other projects which use coverity scans,
or other static analysis scans, on DPDK code won't have to re-disposition
the issue. Also, if we ever start having separate scans of the different
trees, we'll similarly see benefit of not having to mark false positives
multiple times.

/Bruce

  reply	other threads:[~2018-04-27 15:52 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-17 15:50 [dpdk-dev] [PATCH 00/10] Coverity fixes for EAL memory Anatoly Burakov
2018-04-17 15:50 ` [dpdk-dev] [PATCH 01/10] mem: use strlcpy instead of snprintf Anatoly Burakov
2018-04-17 15:50 ` [dpdk-dev] [PATCH 02/10] mem: fix resource leak Anatoly Burakov
2018-04-17 15:50 ` [dpdk-dev] [PATCH 03/10] mem: fix potential double close Anatoly Burakov
2018-04-17 15:50 ` [dpdk-dev] [PATCH 04/10] mem: fix potential resource leak Anatoly Burakov
2018-04-17 15:50 ` [dpdk-dev] [PATCH 05/10] " Anatoly Burakov
2018-04-17 15:50 ` [dpdk-dev] [PATCH 06/10] mem: fix comparing pointer to value Anatoly Burakov
2018-04-17 15:50 ` [dpdk-dev] [PATCH 07/10] mem: fix potential bad unmap Anatoly Burakov
2018-04-17 15:50 ` [dpdk-dev] [PATCH 08/10] mem: fix statement having no effect Anatoly Burakov
2018-04-17 15:50 ` [dpdk-dev] [PATCH 09/10] mem: fix negative return value Anatoly Burakov
2018-04-17 15:50 ` [dpdk-dev] [PATCH 10/10] mem: fix possible use-after-free Anatoly Burakov
2018-04-17 15:56 ` [dpdk-dev] [PATCH 00/10] Coverity fixes for EAL memory Thomas Monjalon
2018-04-17 16:09   ` Burakov, Anatoly
2018-04-17 18:59     ` Thomas Monjalon
2018-04-18 10:37 ` [dpdk-dev] [PATCH v2 " Anatoly Burakov
2018-04-18 10:37 ` [dpdk-dev] [PATCH v2 01/10] mem: use strlcpy instead of snprintf Anatoly Burakov
2018-04-18 10:37 ` [dpdk-dev] [PATCH v2 02/10] mem: fix resource leak Anatoly Burakov
2018-04-18 10:37 ` [dpdk-dev] [PATCH v2 03/10] mem: fix potential double close Anatoly Burakov
2018-04-18 10:37 ` [dpdk-dev] [PATCH v2 04/10] mem: fix potential resource leak Anatoly Burakov
2018-04-18 10:37 ` [dpdk-dev] [PATCH v2 05/10] " Anatoly Burakov
2018-04-18 10:37 ` [dpdk-dev] [PATCH v2 06/10] mem: fix comparing pointer to value Anatoly Burakov
2018-04-18 10:37 ` [dpdk-dev] [PATCH v2 07/10] mem: fix potential bad unmap Anatoly Burakov
2018-04-18 10:37 ` [dpdk-dev] [PATCH v2 08/10] mem: fix statement having no effect Anatoly Burakov
2018-04-18 10:37 ` [dpdk-dev] [PATCH v2 09/10] mem: fix negative return value Anatoly Burakov
2018-04-18 10:37 ` [dpdk-dev] [PATCH v2 10/10] mem: fix possible use-after-free Anatoly Burakov
2018-04-25  9:56 ` [dpdk-dev] [PATCH v3 0/9] Coverity fixes for EAL memory Anatoly Burakov
2018-04-27 17:07   ` [dpdk-dev] [PATCH v4 " Anatoly Burakov
2018-04-27 21:25     ` Thomas Monjalon
2018-04-27 17:07   ` [dpdk-dev] [PATCH v4 1/9] mem: use strlcpy instead of snprintf Anatoly Burakov
2018-04-27 17:07   ` [dpdk-dev] [PATCH v4 2/9] mem: fix resource leak Anatoly Burakov
2018-04-27 17:07   ` [dpdk-dev] [PATCH v4 3/9] mem: fix potential double close Anatoly Burakov
2018-04-30  9:00     ` Bruce Richardson
2018-04-27 17:07   ` [dpdk-dev] [PATCH v4 4/9] mem: fix potential resource leak Anatoly Burakov
2018-04-27 17:07   ` [dpdk-dev] [PATCH v4 5/9] " Anatoly Burakov
2018-04-27 17:07   ` [dpdk-dev] [PATCH v4 6/9] mem: fix comparing pointer to value Anatoly Burakov
2018-04-27 17:07   ` [dpdk-dev] [PATCH v4 7/9] mem: fix potential bad unmap Anatoly Burakov
2018-04-27 17:07   ` [dpdk-dev] [PATCH v4 8/9] mem: fix statement having no effect Anatoly Burakov
2018-04-27 17:07   ` [dpdk-dev] [PATCH v4 9/9] mem: fix possible use-after-free Anatoly Burakov
2018-04-25  9:56 ` [dpdk-dev] [PATCH v3 1/9] mem: use strlcpy instead of snprintf Anatoly Burakov
2018-04-27 15:08   ` Bruce Richardson
2018-04-25  9:56 ` [dpdk-dev] [PATCH v3 2/9] mem: fix resource leak Anatoly Burakov
2018-04-27 15:13   ` Bruce Richardson
2018-04-25  9:56 ` [dpdk-dev] [PATCH v3 3/9] mem: fix potential double close Anatoly Burakov
2018-04-27 15:15   ` Bruce Richardson
2018-04-27 16:56     ` Burakov, Anatoly
2018-04-25  9:56 ` [dpdk-dev] [PATCH v3 4/9] mem: fix potential resource leak Anatoly Burakov
2018-04-27 15:18   ` Bruce Richardson
2018-04-27 15:28     ` Burakov, Anatoly
2018-04-27 15:39     ` Burakov, Anatoly
2018-04-27 15:48       ` Bruce Richardson
2018-04-25  9:56 ` [dpdk-dev] [PATCH v3 5/9] " Anatoly Burakov
2018-04-27 15:21   ` Bruce Richardson
2018-04-27 15:49     ` Burakov, Anatoly
2018-04-27 15:52       ` Bruce Richardson [this message]
2018-04-27 15:55     ` Burakov, Anatoly
2018-04-27 16:27       ` Bruce Richardson
2018-04-27 16:42         ` Burakov, Anatoly
2018-04-25  9:56 ` [dpdk-dev] [PATCH v3 6/9] mem: fix comparing pointer to value Anatoly Burakov
2018-04-27 15:22   ` Bruce Richardson
2018-04-25  9:56 ` [dpdk-dev] [PATCH v3 7/9] mem: fix potential bad unmap Anatoly Burakov
2018-04-27 15:37   ` Bruce Richardson
2018-04-25  9:56 ` [dpdk-dev] [PATCH v3 8/9] mem: fix statement having no effect Anatoly Burakov
2018-04-27 15:39   ` Bruce Richardson
2018-04-25  9:56 ` [dpdk-dev] [PATCH v3 9/9] mem: fix possible use-after-free Anatoly Burakov
2018-04-27 15:45   ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180427155212.GB94056@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).