From: "Mauricio Vásquez" <mauricio.vasquezbernal@studenti.polito.it>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] ivshmem: fix race condition
Date: Fri, 1 Apr 2016 13:17:05 +0200 [thread overview]
Message-ID: <CAPwdgqimV5MN7oRAY27XF=LBD5XAZNmzgRHoO+Ut0JmWT8=Qtw@mail.gmail.com> (raw)
In-Reply-To: <C6ECDF3AB251BE4894318F4E45123697820D9879@IRSMSX109.ger.corp.intel.com>
Hi Anatoly,
On Fri, Apr 1, 2016 at 11:01 AM, Burakov, Anatoly <anatoly.burakov@intel.com
> wrote:
> Hi Mauricio,
>
> > The memory zone could be freed just after adding it to the metadata
> > file and just before marking it as not freeable.
> > This patch changes the locking logic in order to prevent it.
>
> Just a nit: if the stated purpose of the patch is to prevent the memzone
> free
> before adding it to metadata, then it probably should check if the memzone
> wasn't freed before we got the lock (or if it's a valid memzone in the
> first place).
> Probably just checking if the virtual address of the memzone isn't 0 would
> be
> enough. Otherwise looks fine to me.
>
>
The purpose of this patch is to avoid a memzone be freed after it has been
added to the metadata but
before it is marked as not freeable. (that small time interval where it is
possible).
Avoid adding an already freed memzone is another case, I will send a v2
that addresses it.
I used the length of the memzone to check whether the memzone is valid or
not.
> Thanks,
> Anatoly
>
Mauricio Vasquez,
next prev parent reply other threads:[~2016-04-01 11:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 8:16 Mauricio Vasquez B
2016-04-01 9:01 ` Burakov, Anatoly
2016-04-01 11:17 ` Mauricio Vásquez [this message]
2016-04-01 11:22 ` [dpdk-dev] [PATCH v2] " Mauricio Vasquez B
2016-04-01 11:30 ` Burakov, Anatoly
2016-04-01 13:35 ` Thomas Monjalon
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='CAPwdgqimV5MN7oRAY27XF=LBD5XAZNmzgRHoO+Ut0JmWT8=Qtw@mail.gmail.com' \
--to=mauricio.vasquezbernal@studenti.polito.it \
--cc=anatoly.burakov@intel.com \
--cc=dev@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).