DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Question about cd10c42eb5bc ("mem: fix ivshmem freeing")
@ 2016-03-30  8:21 Mauricio Vásquez
  2016-03-30  8:29 ` Burakov, Anatoly
  0 siblings, 1 reply; 5+ messages in thread
From: Mauricio Vásquez @ 2016-03-30  8:21 UTC (permalink / raw)
  To: dev; +Cc: Sergio Gonzalez Monroy, Bruce Richardson, Anatoly Burakov

Dear All,

I was looking at that patch, I can understand its functionality but not its
implementation..

Why to calculate idx?, Just doing "mz->ioremap_addr = mz->phys_addr" would
not be sufficient? After all, the goal is to mark the memzone as used by
ivshmem to forbid  freeing it.

Please corrected if I am missing something.

Thank you,

Mauricio Vasquez,

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Question about cd10c42eb5bc ("mem: fix ivshmem freeing")
  2016-03-30  8:21 [dpdk-dev] Question about cd10c42eb5bc ("mem: fix ivshmem freeing") Mauricio Vásquez
@ 2016-03-30  8:29 ` Burakov, Anatoly
  2016-03-30  9:13   ` Mauricio Vásquez
  0 siblings, 1 reply; 5+ messages in thread
From: Burakov, Anatoly @ 2016-03-30  8:29 UTC (permalink / raw)
  To: Mauricio Vásquez, dev; +Cc: Gonzalez Monroy, Sergio, Richardson, Bruce

Hi Mauricio,

You’re not missing anything. It would be done this way, if the memzone parameter wasn’t const. But it is const, so we have to find the memzone in config to edit it.

Thanks,
Anatoly

From: Mauricio Vásquez [mailto:mauricio.vasquezbernal@studenti.polito.it]
Sent: Wednesday, March 30, 2016 9:22 AM
To: dev@dpdk.org
Cc: Gonzalez Monroy, Sergio <sergio.gonzalez.monroy@intel.com>; Richardson, Bruce <bruce.richardson@intel.com>; Burakov, Anatoly <anatoly.burakov@intel.com>
Subject: Question about cd10c42eb5bc ("mem: fix ivshmem freeing")

Dear All,
I was looking at that patch, I can understand its functionality but not its implementation..
Why to calculate idx?, Just doing "mz->ioremap_addr = mz->phys_addr" would not be sufficient? After all, the goal is to mark the memzone as used by ivshmem to forbid  freeing it.
Please corrected if I am missing something.
Thank you,
Mauricio Vasquez,

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Question about cd10c42eb5bc ("mem: fix ivshmem freeing")
  2016-03-30  8:29 ` Burakov, Anatoly
@ 2016-03-30  9:13   ` Mauricio Vásquez
  2016-03-30 12:10     ` Burakov, Anatoly
  0 siblings, 1 reply; 5+ messages in thread
From: Mauricio Vásquez @ 2016-03-30  9:13 UTC (permalink / raw)
  To: Burakov, Anatoly; +Cc: dev, Gonzalez Monroy, Sergio, Richardson, Bruce

Hi Anatoly,

Thank you very much, I did not take into account that detail.

I have two additional concerns about it:

1. I think it is possible to have a race condition. The memzone is marked
as not freeable after it has been added to the ivshmem device, then it is
possible to free the memzone just after it has been  added to the metadata
but before it is marked as not freeable.
Shouldn't the memzone be marked before adding the memzone to the ivshmem
device?

2. Are the #ifdefs necessary?, we already are in  a file that will only
compiled when ivshmem is enabled.

Thanks,

Mauricio Vasquez,


On Wed, Mar 30, 2016 at 10:29 AM, Burakov, Anatoly <
anatoly.burakov@intel.com> wrote:

> Hi Mauricio,
>
>
>
> You’re not missing anything. It would be done this way, if the memzone
> parameter wasn’t const. But it is const, so we have to find the memzone in
> config to edit it.
>
>
>
> Thanks,
>
> Anatoly
>
>
>
> *From:* Mauricio Vásquez [mailto:mauricio.vasquezbernal@studenti.polito.it]
>
> *Sent:* Wednesday, March 30, 2016 9:22 AM
> *To:* dev@dpdk.org
> *Cc:* Gonzalez Monroy, Sergio <sergio.gonzalez.monroy@intel.com>;
> Richardson, Bruce <bruce.richardson@intel.com>; Burakov, Anatoly <
> anatoly.burakov@intel.com>
> *Subject:* Question about cd10c42eb5bc ("mem: fix ivshmem freeing")
>
>
>
> Dear All,
>
> I was looking at that patch, I can understand its functionality but not
> its implementation..
>
> Why to calculate idx?, Just doing "mz->ioremap_addr = mz->phys_addr" would
> not be sufficient? After all, the goal is to mark the memzone as used by
> ivshmem to forbid  freeing it.
>
> Please corrected if I am missing something.
>
> Thank you,
>
> Mauricio Vasquez,
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Question about cd10c42eb5bc ("mem: fix ivshmem freeing")
  2016-03-30  9:13   ` Mauricio Vásquez
@ 2016-03-30 12:10     ` Burakov, Anatoly
  2016-04-01  8:18       ` Mauricio Vásquez
  0 siblings, 1 reply; 5+ messages in thread
From: Burakov, Anatoly @ 2016-03-30 12:10 UTC (permalink / raw)
  To: Mauricio Vásquez; +Cc: dev, Gonzalez Monroy, Sergio, Richardson, Bruce

Hi Mauricio,

Good points. Would you be willing to prepare a patch to fix these issues?

Thanks,
Anatoly

From: Mauricio Vásquez [mailto:mauricio.vasquezbernal@studenti.polito.it]
Sent: Wednesday, March 30, 2016 10:13 AM
To: Burakov, Anatoly <anatoly.burakov@intel.com>
Cc: dev@dpdk.org; Gonzalez Monroy, Sergio <sergio.gonzalez.monroy@intel.com>; Richardson, Bruce <bruce.richardson@intel.com>
Subject: Re: Question about cd10c42eb5bc ("mem: fix ivshmem freeing")

Hi Anatoly,
Thank you very much, I did not take into account that detail.
I have two additional concerns about it:
1. I think it is possible to have a race condition. The memzone is marked as not freeable after it has been added to the ivshmem device, then it is possible to free the memzone just after it has been  added to the metadata but before it is marked as not freeable.
Shouldn't the memzone be marked before adding the memzone to the ivshmem device?

2. Are the #ifdefs necessary?, we already are in  a file that will only compiled when ivshmem is enabled.
Thanks,
Mauricio Vasquez,


On Wed, Mar 30, 2016 at 10:29 AM, Burakov, Anatoly <anatoly.burakov@intel.com<mailto:anatoly.burakov@intel.com>> wrote:
Hi Mauricio,

You’re not missing anything. It would be done this way, if the memzone parameter wasn’t const. But it is const, so we have to find the memzone in config to edit it.

Thanks,
Anatoly

From: Mauricio Vásquez [mailto:mauricio.vasquezbernal@studenti.polito.it<mailto:mauricio.vasquezbernal@studenti.polito.it>]
Sent: Wednesday, March 30, 2016 9:22 AM
To: dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Gonzalez Monroy, Sergio <sergio.gonzalez.monroy@intel.com<mailto:sergio.gonzalez.monroy@intel.com>>; Richardson, Bruce <bruce.richardson@intel.com<mailto:bruce.richardson@intel.com>>; Burakov, Anatoly <anatoly.burakov@intel.com<mailto:anatoly.burakov@intel.com>>
Subject: Question about cd10c42eb5bc ("mem: fix ivshmem freeing")

Dear All,
I was looking at that patch, I can understand its functionality but not its implementation..
Why to calculate idx?, Just doing "mz->ioremap_addr = mz->phys_addr" would not be sufficient? After all, the goal is to mark the memzone as used by ivshmem to forbid  freeing it.
Please corrected if I am missing something.
Thank you,
Mauricio Vasquez,


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Question about cd10c42eb5bc ("mem: fix ivshmem freeing")
  2016-03-30 12:10     ` Burakov, Anatoly
@ 2016-04-01  8:18       ` Mauricio Vásquez
  0 siblings, 0 replies; 5+ messages in thread
From: Mauricio Vásquez @ 2016-04-01  8:18 UTC (permalink / raw)
  To: Burakov, Anatoly; +Cc: dev, Gonzalez Monroy, Sergio, Richardson, Bruce

Sure: http://dpdk.org/ml/archives/dev/2016-April/036884.html,

On Wed, Mar 30, 2016 at 2:10 PM, Burakov, Anatoly <anatoly.burakov@intel.com
> wrote:

> Hi Mauricio,
>
>
>
> Good points. Would you be willing to prepare a patch to fix these issues?
>
>
>
> Thanks,
>
> Anatoly
>
>
>
> *From:* Mauricio Vásquez [mailto:mauricio.vasquezbernal@studenti.polito.it]
>
> *Sent:* Wednesday, March 30, 2016 10:13 AM
> *To:* Burakov, Anatoly <anatoly.burakov@intel.com>
> *Cc:* dev@dpdk.org; Gonzalez Monroy, Sergio <
> sergio.gonzalez.monroy@intel.com>; Richardson, Bruce <
> bruce.richardson@intel.com>
> *Subject:* Re: Question about cd10c42eb5bc ("mem: fix ivshmem freeing")
>
>
>
> Hi Anatoly,
>
> Thank you very much, I did not take into account that detail.
>
> I have two additional concerns about it:
>
> 1. I think it is possible to have a race condition. The memzone is marked
> as not freeable after it has been added to the ivshmem device, then it is
> possible to free the memzone just after it has been  added to the metadata
> but before it is marked as not freeable.
>
> Shouldn't the memzone be marked before adding the memzone to the ivshmem
> device?
>
>
>
> 2. Are the #ifdefs necessary?, we already are in  a file that will only
> compiled when ivshmem is enabled.
>
> Thanks,
>
> Mauricio Vasquez,
>
>
>
>
>
> On Wed, Mar 30, 2016 at 10:29 AM, Burakov, Anatoly <
> anatoly.burakov@intel.com> wrote:
>
> Hi Mauricio,
>
>
>
> You’re not missing anything. It would be done this way, if the memzone
> parameter wasn’t const. But it is const, so we have to find the memzone in
> config to edit it.
>
>
>
> Thanks,
>
> Anatoly
>
>
>
> *From:* Mauricio Vásquez [mailto:mauricio.vasquezbernal@studenti.polito.it]
>
> *Sent:* Wednesday, March 30, 2016 9:22 AM
> *To:* dev@dpdk.org
> *Cc:* Gonzalez Monroy, Sergio <sergio.gonzalez.monroy@intel.com>;
> Richardson, Bruce <bruce.richardson@intel.com>; Burakov, Anatoly <
> anatoly.burakov@intel.com>
> *Subject:* Question about cd10c42eb5bc ("mem: fix ivshmem freeing")
>
>
>
> Dear All,
>
> I was looking at that patch, I can understand its functionality but not
> its implementation..
>
> Why to calculate idx?, Just doing "mz->ioremap_addr = mz->phys_addr" would
> not be sufficient? After all, the goal is to mark the memzone as used by
> ivshmem to forbid  freeing it.
>
> Please corrected if I am missing something.
>
> Thank you,
>
> Mauricio Vasquez,
>
>
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-04-01  8:18 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-30  8:21 [dpdk-dev] Question about cd10c42eb5bc ("mem: fix ivshmem freeing") Mauricio Vásquez
2016-03-30  8:29 ` Burakov, Anatoly
2016-03-30  9:13   ` Mauricio Vásquez
2016-03-30 12:10     ` Burakov, Anatoly
2016-04-01  8:18       ` Mauricio Vásquez

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).