From: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
To: Akhil Goyal <akhil.goyal@nxp.com>,
"Zhang, Roy Fan" <roy.fan.zhang@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 1/2] crypto/scheduler: set null pointer after freeing
Date: Fri, 27 Apr 2018 11:36:12 +0000 [thread overview]
Message-ID: <E115CCD9D858EF4F90C690B0DCB4D8976CCDF011@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <5e2f48d7-c451-c550-5ddc-70263a278e2f@nxp.com>
Hi Akhil,
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Friday, April 27, 2018 9:47 AM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Cc: dev@dpdk.org; stable@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] crypto/scheduler: set null pointer after
> freeing
>
> Hi Pablo,
>
> On 4/26/2018 8:39 PM, Pablo de Lara wrote:
> > When freeing memory, pointers should be set to NULL, to avoid memory
> > corruption/segmentation faults.
>
> Shouldn't this be handled in the rte_free itself. A lot of other driver are also not
> setting null after rte_free.
> This would require change at a lot of places if this is not handled in rte_free.
>
The glibc function "free" works the same way. Users are responsible for
setting to NULL these pointers (because sometimes, it is not necessary to do such thing).
Anyway, in case we still wanted to change it, we would need to pass a pointer
to a pointer in rte_free, which would imply an API breakage.
Thanks,
Pablo
> Thanks,
> Akhil
next prev parent reply other threads:[~2018-04-27 11:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-26 15:09 Pablo de Lara
2018-04-26 15:09 ` [dpdk-dev] [PATCH 2/2] crypto/scheduler: fix memory leak Pablo de Lara
2018-05-08 12:45 ` Zhang, Roy Fan
2018-05-08 15:53 ` De Lara Guarch, Pablo
2018-04-27 8:47 ` [dpdk-dev] [PATCH 1/2] crypto/scheduler: set null pointer after freeing Akhil Goyal
2018-04-27 11:36 ` De Lara Guarch, Pablo [this message]
2018-04-27 11:58 ` Akhil Goyal
2018-04-27 12:37 ` Van Haaren, Harry
2018-04-27 13:09 ` Bruce Richardson
2018-05-08 11:28 ` Zhang, Roy Fan
2018-05-08 15:53 ` De Lara Guarch, Pablo
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=E115CCD9D858EF4F90C690B0DCB4D8976CCDF011@IRSMSX108.ger.corp.intel.com \
--to=pablo.de.lara.guarch@intel.com \
--cc=akhil.goyal@nxp.com \
--cc=dev@dpdk.org \
--cc=roy.fan.zhang@intel.com \
--cc=stable@dpdk.org \
/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).