DPDK patches and discussions
 help / color / mirror / Atom feed
* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory
       [not found] <20200420070508.645533-1-fengli@smartx.com>
@ 2020-04-20  7:07 ` Li Feng
  2020-04-20  7:13   ` David Marchand
  2020-04-23 15:43 ` [dpdk-dev] [PATCH v2] " Li Feng
  1 sibling, 1 reply; 19+ messages in thread
From: Li Feng @ 2020-04-20  7:07 UTC (permalink / raw)
  To: Anatoly Burakov; +Cc: lifeng1519, Kyle Zhang, dev

Add cc dev@dpdk.org

Thanks,

Feng Li

Li Feng <fengli@smartx.com> 于2020年4月20日周一 下午3:04写道:
>
> Avoid dump all mmapped memory to coredump file when crash.
> Otherwise it will very large and it's hard to analyze with gdb.
>
> In my test, it will dump 128GiB memory to coredump file when integrated
> to spdk with default configuration.
>
> Signed-off-by: Li Feng <fengli@smartx.com>
> ---
>  lib/librte_eal/common/eal_common_memory.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
> index cc7d54e0c..cc6743d56 100644
> --- a/lib/librte_eal/common/eal_common_memory.c
> +++ b/lib/librte_eal/common/eal_common_memory.c
> @@ -102,6 +102,13 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
>                 if (mapped_addr == MAP_FAILED && allow_shrink)
>                         *size -= page_sz;
>
> +               if (mapped_addr != MAP_FAILED) {
> +                       if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0)
> +                               RTE_LOG(INFO, EAL, "MADV_DONTDUMP advice setting failed.\n");
> +                       RTE_LOG(DEBUG, EAL, "madvise with MADV_DONTDUMP, addr: %p size: %ld\n",
> +                               mapped_addr, (size_t)map_sz);
> +               }
> +
>                 if (mapped_addr != MAP_FAILED && addr_is_hint &&
>                     mapped_addr != requested_addr) {
>                         try++;
> --
> 2.11.0
>

-- 
The SmartX email address is only for business purpose. Any sent message 
that is not related to the business is not authorized or permitted by 
SmartX.
本邮箱为北京志凌海纳科技有限公司(SmartX)工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权.



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

* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory
  2020-04-20  7:07 ` [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory Li Feng
@ 2020-04-20  7:13   ` David Marchand
  2020-04-20  9:40     ` Feng Li
  0 siblings, 1 reply; 19+ messages in thread
From: David Marchand @ 2020-04-20  7:13 UTC (permalink / raw)
  To: Li Feng; +Cc: Anatoly Burakov, lifeng1519, Kyle Zhang, dev

On Mon, Apr 20, 2020 at 9:10 AM Li Feng <fengli@smartx.com> wrote:
> Li Feng <fengli@smartx.com> 于2020年4月20日周一 下午3:04写道:
> >
> > Avoid dump all mmapped memory to coredump file when crash.
> > Otherwise it will very large and it's hard to analyze with gdb.
> >
> > In my test, it will dump 128GiB memory to coredump file when integrated
> > to spdk with default configuration.

Can you test with current master which has this change?
https://git.dpdk.org/dpdk/commit?id=8a4baf06c17a806696fb10aba36fce7471983028

Thanks.

-- 
David Marchand


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

* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory
  2020-04-20  7:13   ` David Marchand
@ 2020-04-20  9:40     ` Feng Li
  2020-04-21  7:41       ` David Marchand
  0 siblings, 1 reply; 19+ messages in thread
From: Feng Li @ 2020-04-20  9:40 UTC (permalink / raw)
  To: David Marchand; +Cc: Li Feng, Anatoly Burakov, Kyle Zhang, dev

Thank you, Marchand,

I have just tested your patch, and it doesn't work.
The core dump file is still very very large, the same to virtual memory size.

David Marchand <david.marchand@redhat.com> 于2020年4月20日周一 下午3:13写道:
>
> On Mon, Apr 20, 2020 at 9:10 AM Li Feng <fengli@smartx.com> wrote:
> > Li Feng <fengli@smartx.com> 于2020年4月20日周一 下午3:04写道:
> > >
> > > Avoid dump all mmapped memory to coredump file when crash.
> > > Otherwise it will very large and it's hard to analyze with gdb.
> > >
> > > In my test, it will dump 128GiB memory to coredump file when integrated
> > > to spdk with default configuration.
>
> Can you test with current master which has this change?
> https://git.dpdk.org/dpdk/commit?id=8a4baf06c17a806696fb10aba36fce7471983028
>
> Thanks.
>
> --
> David Marchand
>

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

* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory
  2020-04-20  9:40     ` Feng Li
@ 2020-04-21  7:41       ` David Marchand
  2020-04-21 11:06         ` Feng Li
  0 siblings, 1 reply; 19+ messages in thread
From: David Marchand @ 2020-04-21  7:41 UTC (permalink / raw)
  To: Feng Li, Anatoly Burakov; +Cc: Li Feng, Kyle Zhang, dev

On Mon, Apr 20, 2020 at 11:41 AM Feng Li <lifeng1519@gmail.com> wrote:
>
> Thank you, Marchand,

David is fine.

>
> I have just tested your patch, and it doesn't work.
> The core dump file is still very very large, the same to virtual memory size.

Please double check that the patch is in.
I remember checking coredump size with my patch.

This needs more investigation but I don't have time atm.
Anatoly, opinion?


-- 
David Marchand


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

* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory
  2020-04-21  7:41       ` David Marchand
@ 2020-04-21 11:06         ` Feng Li
  2020-04-21 12:19           ` Burakov, Anatoly
  0 siblings, 1 reply; 19+ messages in thread
From: Feng Li @ 2020-04-21 11:06 UTC (permalink / raw)
  To: David Marchand; +Cc: Anatoly Burakov, Li Feng, Kyle Zhang, dev, fanyang

Hi David,

Mmap with PROT_NONE does not affected the core dump size.

Here is a simple test prog:

#include <sys/mman.h>
#include <time.h>
#include <stdint.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char** argv) {
    // FIXME(fengli): XXXXX
    uint64_t gb = atoi(argv[1]);
    void* ptr = mmap(0, gb << 30, PROT_NONE, MAP_PRIVATE |
MAP_ANONYMOUS, -1, 0);
    if (ptr == (void*)-1) {
        perror("[-] mmap failed with MAP_PRIVATE | MAP_ANONYMOUS");
        exit(1);
    }
    while(1)
        sleep(1);
    return 0;
}

Thanks.

David Marchand <david.marchand@redhat.com> 于2020年4月21日周二 下午3:41写道:
>
> On Mon, Apr 20, 2020 at 11:41 AM Feng Li <lifeng1519@gmail.com> wrote:
> >
> > Thank you, Marchand,
>
> David is fine.
>
> >
> > I have just tested your patch, and it doesn't work.
> > The core dump file is still very very large, the same to virtual memory size.
>
> Please double check that the patch is in.
> I remember checking coredump size with my patch.
>
> This needs more investigation but I don't have time atm.
> Anatoly, opinion?
>
>
> --
> David Marchand
>

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

* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory
  2020-04-21 11:06         ` Feng Li
@ 2020-04-21 12:19           ` Burakov, Anatoly
  2020-04-21 16:38             ` Feng Li
  0 siblings, 1 reply; 19+ messages in thread
From: Burakov, Anatoly @ 2020-04-21 12:19 UTC (permalink / raw)
  To: Feng Li, David Marchand; +Cc: Li Feng, Kyle Zhang, dev, fanyang

On 21-Apr-20 12:06 PM, Feng Li wrote:
> #include <sys/mman.h>
> #include <time.h>
> #include <stdint.h>
> #include <unistd.h>
> #include <stdlib.h>
> #include <stdio.h>
> 
> int main(int argc, char** argv) {
>      // FIXME(fengli): XXXXX
>      uint64_t gb = atoi(argv[1]);
>      void* ptr = mmap(0, gb << 30, PROT_NONE, MAP_PRIVATE |
> MAP_ANONYMOUS, -1, 0);
>      if (ptr == (void*)-1) {
>          perror("[-] mmap failed with MAP_PRIVATE | MAP_ANONYMOUS");
>          exit(1);
>      }
>      while(1)
>          sleep(1);
>      return 0;
> }

DONTDUMP is available since Linux 3.4. I presume our minimum kernel 
version is higher than that.

I have little idea of how dumping works, but reading the manpage for 
madvise, DONTDUMP should be the way to go here. Also, reading up on 
PROT_NONE, i can't find any references to this memory necessarily being 
excluded from core dumps.

That said, I've run the program above, and i got a core dump sized 
~100K. Do i need any special configuration to trigger core dump that 
would include that anonymous memory?

-- 
Thanks,
Anatoly

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

* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory
  2020-04-21 12:19           ` Burakov, Anatoly
@ 2020-04-21 16:38             ` Feng Li
  2020-04-21 17:02               ` Burakov, Anatoly
  0 siblings, 1 reply; 19+ messages in thread
From: Feng Li @ 2020-04-21 16:38 UTC (permalink / raw)
  To: Burakov, Anatoly; +Cc: David Marchand, Li Feng, Kyle Zhang, dev, fanyang

Hi Anatoly,

This program could run like this:
gcc test_map.c
./a.out 2 &
gcore `pidof a.out`

You will get a core dump sized to 2GiB.

Thanks,
Feng Li

Burakov, Anatoly <anatoly.burakov@intel.com> 于2020年4月21日周二 下午8:19写道:
>
> On 21-Apr-20 12:06 PM, Feng Li wrote:
> > #include <sys/mman.h>
> > #include <time.h>
> > #include <stdint.h>
> > #include <unistd.h>
> > #include <stdlib.h>
> > #include <stdio.h>
> >
> > int main(int argc, char** argv) {
> >      // FIXME(fengli): XXXXX
> >      uint64_t gb = atoi(argv[1]);
> >      void* ptr = mmap(0, gb << 30, PROT_NONE, MAP_PRIVATE |
> > MAP_ANONYMOUS, -1, 0);
> >      if (ptr == (void*)-1) {
> >          perror("[-] mmap failed with MAP_PRIVATE | MAP_ANONYMOUS");
> >          exit(1);
> >      }
> >      while(1)
> >          sleep(1);
> >      return 0;
> > }
>
> DONTDUMP is available since Linux 3.4. I presume our minimum kernel
> version is higher than that.
>
> I have little idea of how dumping works, but reading the manpage for
> madvise, DONTDUMP should be the way to go here. Also, reading up on
> PROT_NONE, i can't find any references to this memory necessarily being
> excluded from core dumps.
>
> That said, I've run the program above, and i got a core dump sized
> ~100K. Do i need any special configuration to trigger core dump that
> would include that anonymous memory?
>
> --
> Thanks,
> Anatoly

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

* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory
  2020-04-21 16:38             ` Feng Li
@ 2020-04-21 17:02               ` Burakov, Anatoly
  2020-04-22  3:13                 ` Li Feng
  0 siblings, 1 reply; 19+ messages in thread
From: Burakov, Anatoly @ 2020-04-21 17:02 UTC (permalink / raw)
  To: Feng Li; +Cc: David Marchand, Li Feng, Kyle Zhang, dev, fanyang

On 21-Apr-20 5:38 PM, Feng Li wrote:
> Hi Anatoly,
> 
> This program could run like this:
> gcc test_map.c
> ./a.out 2 &
> gcore `pidof a.out`
> 
> You will get a core dump sized to 2GiB.
> 
> Thanks,
> Feng Li
> 

I did just that, and my core dump was ~100K in size. Hence my asking 
about any special configuration required.

-- 
Thanks,
Anatoly

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

* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory
  2020-04-21 17:02               ` Burakov, Anatoly
@ 2020-04-22  3:13                 ` Li Feng
  2020-04-22  9:53                   ` Burakov, Anatoly
  0 siblings, 1 reply; 19+ messages in thread
From: Li Feng @ 2020-04-22  3:13 UTC (permalink / raw)
  To: Burakov, Anatoly; +Cc: Feng Li, David Marchand, Kyle Zhang, dev, Yang Fan

Really?So weird.
I have tested on 4 machines, running CentOS 7.
The core dump size is the same as the first argument GiB.

Thanks,

Feng Li

Burakov, Anatoly <anatoly.burakov@intel.com> 于2020年4月22日周三 上午1:02写道:
>
> On 21-Apr-20 5:38 PM, Feng Li wrote:
> > Hi Anatoly,
> >
> > This program could run like this:
> > gcc test_map.c
> > ./a.out 2 &
> > gcore `pidof a.out`
> >
> > You will get a core dump sized to 2GiB.
> >
> > Thanks,
> > Feng Li
> >
>
> I did just that, and my core dump was ~100K in size. Hence my asking
> about any special configuration required.
>
> --
> Thanks,
> Anatoly

-- 
The SmartX email address is only for business purpose. Any sent message 
that is not related to the business is not authorized or permitted by 
SmartX.
本邮箱为北京志凌海纳科技有限公司(SmartX)工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权.



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

* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory
  2020-04-22  3:13                 ` Li Feng
@ 2020-04-22  9:53                   ` Burakov, Anatoly
       [not found]                     ` <CAEK8JBCdfZJiKNjDNgC9nDGLni9Dvw+U1doRFnh+zkAs5TXEsg@mail.gmail.com>
  0 siblings, 1 reply; 19+ messages in thread
From: Burakov, Anatoly @ 2020-04-22  9:53 UTC (permalink / raw)
  To: Li Feng; +Cc: Feng Li, David Marchand, Kyle Zhang, dev, Yang Fan

On 22-Apr-20 4:13 AM, Li Feng wrote:
> Really?So weird.
> I have tested on 4 machines, running CentOS 7.
> The core dump size is the same as the first argument GiB.
> 
> Thanks,
> 
> Feng Li
> 
> Burakov, Anatoly <anatoly.burakov@intel.com> 于2020年4月22日周三 上午1:02写道:
>>
>> On 21-Apr-20 5:38 PM, Feng Li wrote:
>>> Hi Anatoly,
>>>
>>> This program could run like this:
>>> gcc test_map.c
>>> ./a.out 2 &
>>> gcore `pidof a.out`
>>>
>>> You will get a core dump sized to 2GiB.
>>>
>>> Thanks,
>>> Feng Li
>>>
>>
>> I did just that, and my core dump was ~100K in size. Hence my asking
>> about any special configuration required.
>>
>> --
>> Thanks,
>> Anatoly
> 

Apologies, i've looked at the wrong core dump file. I do get a 2G core 
dump out of it.

However, i've added madvise call for that memory and run the exact same 
command line you gave me, and i can see multiple core dump files, some 
of them are 2G files. Does that mean that MADV_DONTDUMP doesn't work?

-- 
Thanks,
Anatoly

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

* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory
       [not found]                     ` <CAEK8JBCdfZJiKNjDNgC9nDGLni9Dvw+U1doRFnh+zkAs5TXEsg@mail.gmail.com>
@ 2020-04-23 12:22                       ` Burakov, Anatoly
  0 siblings, 0 replies; 19+ messages in thread
From: Burakov, Anatoly @ 2020-04-23 12:22 UTC (permalink / raw)
  To: Feng Li; +Cc: Li Feng, David Marchand, Kyle Zhang, dev, Yang Fan

On 23-Apr-20 7:36 AM, Feng Li wrote:
> Hi,
> I have tested as follows, the core dump file is ~ 200KB.
> It should generate one core dump file each crash.
> 
> #include <sys/mman.h>
> #include <time.h>
> #include <stdint.h>
> #include <unistd.h>
> #include <stdlib.h>
> #include <stdio.h>
> 
> int main(int argc, char** argv) {
> // FIXME(fengli): XXXXX
> uint64_t size = 1<<30;
> void* ptr = mmap(0, size , PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> if (ptr == (void*)-1) {
> perror("[-] mmap failed with MAP_PRIVATE | MAP_ANONYMOUS");
> exit(1);
> }
> if (madvise(ptr, size , MADV_DONTDUMP) != 0)
> perror("[-] madvise failed");
> while(1)
> sleep(1);
> return 0;
> }
> 

That's odd, your code works. Mine, even though it did the same thing, 
didn't work the same way. My compiler must like you more than it likes 
me :) (or perhaps i had a typo...)

Anyway, i can see that this indeed prevents core dumps on madvise'd 
memory (i've also tested it with PROT_NONE).

I'll go ahead and ack the original patch then.

-- 
Thanks,
Anatoly

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

* [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory
       [not found] <20200420070508.645533-1-fengli@smartx.com>
  2020-04-20  7:07 ` [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory Li Feng
@ 2020-04-23 15:43 ` Li Feng
  2020-04-23 16:33   ` Burakov, Anatoly
  1 sibling, 1 reply; 19+ messages in thread
From: Li Feng @ 2020-04-23 15:43 UTC (permalink / raw)
  To: Anatoly Burakov; +Cc: dev, kyle, lifeng1519, fanyang, Li Feng

Avoid dump all mapped memory to a core dump file when crash.
Otherwise it will very large and it's hard to analyze with gdb.

In my test, it will dump 128GiB memory to a core dump file when integrated
to spdk with default configuration.

Signed-off-by: Li Feng <fengli@smartx.com>
---
 lib/librte_eal/common/eal_common_memory.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
index cc7d54e0c..2d9564b28 100644
--- a/lib/librte_eal/common/eal_common_memory.c
+++ b/lib/librte_eal/common/eal_common_memory.c
@@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
 		after_len = RTE_PTR_DIFF(map_end, aligned_end);
 		if (after_len > 0)
 			munmap(aligned_end, after_len);
+
+		/*
+		 * Exclude this pages from a core dump.
+		 */
+		if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0)
+			RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
+				strerror(errno));
+	} else {
+		/*
+		 * Exclude this pages from a core dump.
+		 */
+		if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0)
+			RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
+				strerror(errno));
 	}
 
 	return aligned_addr;
-- 
2.11.0


-- 
The SmartX email address is only for business purpose. Any sent message 
that is not related to the business is not authorized or permitted by 
SmartX.
本邮箱为北京志凌海纳科技有限公司(SmartX)工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权.



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

* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory
  2020-04-23 15:43 ` [dpdk-dev] [PATCH v2] " Li Feng
@ 2020-04-23 16:33   ` Burakov, Anatoly
  2020-04-23 20:04     ` David Marchand
  0 siblings, 1 reply; 19+ messages in thread
From: Burakov, Anatoly @ 2020-04-23 16:33 UTC (permalink / raw)
  To: Li Feng; +Cc: dev, kyle, lifeng1519, fanyang

On 23-Apr-20 4:43 PM, Li Feng wrote:
> Avoid dump all mapped memory to a core dump file when crash.
> Otherwise it will very large and it's hard to analyze with gdb.
> 
> In my test, it will dump 128GiB memory to a core dump file when integrated
> to spdk with default configuration.

Suggested rewording:

Currently, even though memory is mapped with PROT_NONE, this does not 
cause it to be excluded from core dumps. This is counter-productive, 
because in a lot of cases, this memory will go unused (e.g. when the 
memory subsystem preallocates VA space but hasn't yet mapped physical 
pages into it).

Use `madvise()` call with MADV_DONTDUMP parameter to exclude the 
unmapped memory from being dumped.

> 
> Signed-off-by: Li Feng <fengli@smartx.com>
> ---
>   lib/librte_eal/common/eal_common_memory.c | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
> 
> diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
> index cc7d54e0c..2d9564b28 100644
> --- a/lib/librte_eal/common/eal_common_memory.c
> +++ b/lib/librte_eal/common/eal_common_memory.c
> @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
>   		after_len = RTE_PTR_DIFF(map_end, aligned_end);
>   		if (after_len > 0)
>   			munmap(aligned_end, after_len);
> +
> +		/*
> +		 * Exclude this pages from a core dump.
> +		 */
> +		if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0)
> +			RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
> +				strerror(errno)); > +	} else {
> +		/*
> +		 * Exclude this pages from a core dump.
> +		 */
> +		if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0)
> +			RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
> +				strerror(errno));
>   	}
>   
>   	return aligned_addr;
> 

For the contents of this patch,

Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>

However, even though this is good to have, after some more thought, i 
believe the fix is incomplete, because this is not the only place we're 
reserving anonymous memory. We're also doing so in 
`eal_memalloc.c:free_seg()`, so an `madvise()` call should also be added 
there.

@David, now that i think of it, the PROT_NONE patch also was incomplete, 
as we only set PROT_NONE to memory that's initially reserved, but not 
when it's unmapped and returned back to the pool of anonymous memory. 
So, eal_memalloc.c should also remap anonymous memory with PROT_NONE.

@Li Feng, would you be so kind as to provide a patch replacing PROT_READ 
with PROT_NONE in eal_memalloc.c as well? Thank you very much!

-- 
Thanks,
Anatoly

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

* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory
  2020-04-23 16:33   ` Burakov, Anatoly
@ 2020-04-23 20:04     ` David Marchand
  2020-04-24  9:12       ` Burakov, Anatoly
  0 siblings, 1 reply; 19+ messages in thread
From: David Marchand @ 2020-04-23 20:04 UTC (permalink / raw)
  To: Burakov, Anatoly; +Cc: Li Feng, dev, Kyle Zhang, Feng Li, fanyang

On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly
<anatoly.burakov@intel.com> wrote:
> > diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
> > index cc7d54e0c..2d9564b28 100644
> > --- a/lib/librte_eal/common/eal_common_memory.c
> > +++ b/lib/librte_eal/common/eal_common_memory.c
> > @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
> >               after_len = RTE_PTR_DIFF(map_end, aligned_end);
> >               if (after_len > 0)
> >                       munmap(aligned_end, after_len);
> > +
> > +             /*
> > +              * Exclude this pages from a core dump.
> > +              */
> > +             if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0)
> > +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
> > +                             strerror(errno));> +   } else {
> > +             /*
> > +              * Exclude this pages from a core dump.
> > +              */
> > +             if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0)
> > +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
> > +                             strerror(errno));
> >       }
> >
> >       return aligned_addr;
> >
>
> For the contents of this patch,

MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to
be a MADV_NOCORE option on FreeBSD.
1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/


>
> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
>
> However, even though this is good to have, after some more thought, i
> believe the fix is incomplete, because this is not the only place we're
> reserving anonymous memory. We're also doing so in
> `eal_memalloc.c:free_seg()`, so an `madvise()` call should also be added
> there.
>
> @David, now that i think of it, the PROT_NONE patch also was incomplete,
> as we only set PROT_NONE to memory that's initially reserved, but not
> when it's unmapped and returned back to the pool of anonymous memory.
> So, eal_memalloc.c should also remap anonymous memory with PROT_NONE.

I can't disagree if you say so :-).

>
> @Li Feng, would you be so kind as to provide a patch replacing PROT_READ
> with PROT_NONE in eal_memalloc.c as well? Thank you very much!
>

Once we have the proper fixes, I'd like to get this Cc: stable@dpdk.org.
Thanks.


-- 
David Marchand


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

* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory
  2020-04-23 20:04     ` David Marchand
@ 2020-04-24  9:12       ` Burakov, Anatoly
  2020-04-24  9:14         ` Bruce Richardson
  0 siblings, 1 reply; 19+ messages in thread
From: Burakov, Anatoly @ 2020-04-24  9:12 UTC (permalink / raw)
  To: David Marchand; +Cc: Li Feng, dev, Kyle Zhang, Feng Li, fanyang

On 23-Apr-20 9:04 PM, David Marchand wrote:
> On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly
> <anatoly.burakov@intel.com> wrote:
>>> diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
>>> index cc7d54e0c..2d9564b28 100644
>>> --- a/lib/librte_eal/common/eal_common_memory.c
>>> +++ b/lib/librte_eal/common/eal_common_memory.c
>>> @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
>>>                after_len = RTE_PTR_DIFF(map_end, aligned_end);
>>>                if (after_len > 0)
>>>                        munmap(aligned_end, after_len);
>>> +
>>> +             /*
>>> +              * Exclude this pages from a core dump.
>>> +              */
>>> +             if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0)
>>> +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
>>> +                             strerror(errno));> +   } else {
>>> +             /*
>>> +              * Exclude this pages from a core dump.
>>> +              */
>>> +             if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0)
>>> +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
>>> +                             strerror(errno));
>>>        }
>>>
>>>        return aligned_addr;
>>>
>>
>> For the contents of this patch,
> 
> MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to
> be a MADV_NOCORE option on FreeBSD.
> 1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/
> 
> 

Oh, right, so this would probably not compile on FreeBSD. Perhaps this 
function would have to be OS-specific after all (or call into an 
OS-specific madvise() after reserving the memory area).

>>
>> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
>>
>> However, even though this is good to have, after some more thought, i
>> believe the fix is incomplete, because this is not the only place we're
>> reserving anonymous memory. We're also doing so in
>> `eal_memalloc.c:free_seg()`, so an `madvise()` call should also be added
>> there.
>>
>> @David, now that i think of it, the PROT_NONE patch also was incomplete,
>> as we only set PROT_NONE to memory that's initially reserved, but not
>> when it's unmapped and returned back to the pool of anonymous memory.
>> So, eal_memalloc.c should also remap anonymous memory with PROT_NONE.
> 
> I can't disagree if you say so :-).

Nice to have that kind of power! *evil laugh*

> 
>>
>> @Li Feng, would you be so kind as to provide a patch replacing PROT_READ
>> with PROT_NONE in eal_memalloc.c as well? Thank you very much!
>>
> 
> Once we have the proper fixes, I'd like to get this Cc: stable@dpdk.org.
> Thanks.
> 
> 


-- 
Thanks,
Anatoly

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

* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory
  2020-04-24  9:12       ` Burakov, Anatoly
@ 2020-04-24  9:14         ` Bruce Richardson
  2020-04-24  9:33           ` Feng Li
  0 siblings, 1 reply; 19+ messages in thread
From: Bruce Richardson @ 2020-04-24  9:14 UTC (permalink / raw)
  To: Burakov, Anatoly
  Cc: David Marchand, Li Feng, dev, Kyle Zhang, Feng Li, fanyang

On Fri, Apr 24, 2020 at 10:12:10AM +0100, Burakov, Anatoly wrote:
> On 23-Apr-20 9:04 PM, David Marchand wrote:
> > On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com> wrote:
> > > > diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
> > > > index cc7d54e0c..2d9564b28 100644
> > > > --- a/lib/librte_eal/common/eal_common_memory.c
> > > > +++ b/lib/librte_eal/common/eal_common_memory.c
> > > > @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
> > > >                after_len = RTE_PTR_DIFF(map_end, aligned_end);
> > > >                if (after_len > 0)
> > > >                        munmap(aligned_end, after_len);
> > > > +
> > > > +             /*
> > > > +              * Exclude this pages from a core dump.
> > > > +              */
> > > > +             if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0)
> > > > +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
> > > > +                             strerror(errno));> +   } else {
> > > > +             /*
> > > > +              * Exclude this pages from a core dump.
> > > > +              */
> > > > +             if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0)
> > > > +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
> > > > +                             strerror(errno));
> > > >        }
> > > > 
> > > >        return aligned_addr;
> > > > 
> > > 
> > > For the contents of this patch,
> > 
> > MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to
> > be a MADV_NOCORE option on FreeBSD.
> > 1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/
> > 
> > 
> 
> Oh, right, so this would probably not compile on FreeBSD. Perhaps this
> function would have to be OS-specific after all (or call into an OS-specific
> madvise() after reserving the memory area).
> 

Is it just a differently named flag? If so, I think a single #ifdef macro
won't kill us in the common code.


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

* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory
  2020-04-24  9:14         ` Bruce Richardson
@ 2020-04-24  9:33           ` Feng Li
  2020-04-24 11:00             ` Burakov, Anatoly
  0 siblings, 1 reply; 19+ messages in thread
From: Feng Li @ 2020-04-24  9:33 UTC (permalink / raw)
  To: Bruce Richardson
  Cc: Burakov, Anatoly, David Marchand, Li Feng, dev, Kyle Zhang, Yang Fan

Bruce Richardson <bruce.richardson@intel.com> 于2020年4月24日周五 下午5:14写道:
>
> On Fri, Apr 24, 2020 at 10:12:10AM +0100, Burakov, Anatoly wrote:
> > On 23-Apr-20 9:04 PM, David Marchand wrote:
> > > On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly
> > > <anatoly.burakov@intel.com> wrote:
> > > > > diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
> > > > > index cc7d54e0c..2d9564b28 100644
> > > > > --- a/lib/librte_eal/common/eal_common_memory.c
> > > > > +++ b/lib/librte_eal/common/eal_common_memory.c
> > > > > @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
> > > > >                after_len = RTE_PTR_DIFF(map_end, aligned_end);
> > > > >                if (after_len > 0)
> > > > >                        munmap(aligned_end, after_len);
> > > > > +
> > > > > +             /*
> > > > > +              * Exclude this pages from a core dump.
> > > > > +              */
> > > > > +             if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0)
> > > > > +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
> > > > > +                             strerror(errno));> +   } else {
> > > > > +             /*
> > > > > +              * Exclude this pages from a core dump.
> > > > > +              */
> > > > > +             if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0)
> > > > > +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
> > > > > +                             strerror(errno));
> > > > >        }
> > > > >
> > > > >        return aligned_addr;
> > > > >
> > > >
> > > > For the contents of this patch,
> > >
> > > MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to
> > > be a MADV_NOCORE option on FreeBSD.
> > > 1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/
> > >
> > >
> >
> > Oh, right, so this would probably not compile on FreeBSD. Perhaps this
> > function would have to be OS-specific after all (or call into an OS-specific
> > madvise() after reserving the memory area).
> >
>
> Is it just a differently named flag? If so, I think a single #ifdef macro
> won't kill us in the common code.
>
Just the flag name is different.
I should use RTE_EXEC_ENV_FREEBSD and RTE_EXEC_ENV_LINUX, right?

Another question, in `eal_memalloc.c:alloc_seg`, I should undo the
DONTMAP of the memory region.
Right? @Anatoly

Just few minutes, I have prepared a patch for the OS-specific code:
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -443,4 +443,20 @@ rte_option_usage(void);
 uint64_t
 eal_get_baseaddr(void);

+/**
+ * @internal
+ * Exclude this pages from a core dump.
+ *
+ * @param addr
+ *  The memory region starts.
+ *
+ * @param len
+ *  The memory region length..
+ *
+ * @return
+ * returns 0 or -errno
+ */
+int
+eal_madvise_dontdump(void* addr, size_t len);
+
 #endif /* _EAL_PRIVATE_H_ */
diff --git a/lib/librte_eal/freebsd/eal_memory.c
b/lib/librte_eal/freebsd/eal_memory.c
index a97d8f0f0..585042dde 100644
--- a/lib/librte_eal/freebsd/eal_memory.c
+++ b/lib/librte_eal/freebsd/eal_memory.c
@@ -534,3 +534,9 @@ rte_eal_memseg_init(void)
  memseg_primary_init() :
  memseg_secondary_init();
 }
+
+int
+eal_madvise_dontdump(void* addr, size_t len)
+{
+ return madvise(addr, len, MADV_NOCORE);
+}
diff --git a/lib/librte_eal/linux/eal_memory.c
b/lib/librte_eal/linux/eal_memory.c
index 7a9c97ff8..cfdbfccfe 100644
--- a/lib/librte_eal/linux/eal_memory.c
+++ b/lib/librte_eal/linux/eal_memory.c
@@ -2479,3 +2479,9 @@ rte_eal_memseg_init(void)
 #endif
  memseg_secondary_init();
 }
+
+int
+eal_madvise_dontdump(void* addr, size_t len)
+{
+ return madvise(addr, len, MADV_DONTDUMP);
+}

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

* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory
  2020-04-24  9:33           ` Feng Li
@ 2020-04-24 11:00             ` Burakov, Anatoly
  2020-04-24 12:03               ` Li Feng
  0 siblings, 1 reply; 19+ messages in thread
From: Burakov, Anatoly @ 2020-04-24 11:00 UTC (permalink / raw)
  To: Feng Li, Bruce Richardson
  Cc: David Marchand, Li Feng, dev, Kyle Zhang, Yang Fan

On 24-Apr-20 10:33 AM, Feng Li wrote:
> Bruce Richardson <bruce.richardson@intel.com> 于2020年4月24日周五 下午5:14写道:
>>
>> On Fri, Apr 24, 2020 at 10:12:10AM +0100, Burakov, Anatoly wrote:
>>> On 23-Apr-20 9:04 PM, David Marchand wrote:
>>>> On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly
>>>> <anatoly.burakov@intel.com> wrote:
>>>>>> diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
>>>>>> index cc7d54e0c..2d9564b28 100644
>>>>>> --- a/lib/librte_eal/common/eal_common_memory.c
>>>>>> +++ b/lib/librte_eal/common/eal_common_memory.c
>>>>>> @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
>>>>>>                 after_len = RTE_PTR_DIFF(map_end, aligned_end);
>>>>>>                 if (after_len > 0)
>>>>>>                         munmap(aligned_end, after_len);
>>>>>> +
>>>>>> +             /*
>>>>>> +              * Exclude this pages from a core dump.
>>>>>> +              */
>>>>>> +             if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0)
>>>>>> +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
>>>>>> +                             strerror(errno));> +   } else {
>>>>>> +             /*
>>>>>> +              * Exclude this pages from a core dump.
>>>>>> +              */
>>>>>> +             if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0)
>>>>>> +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
>>>>>> +                             strerror(errno));
>>>>>>         }
>>>>>>
>>>>>>         return aligned_addr;
>>>>>>
>>>>>
>>>>> For the contents of this patch,
>>>>
>>>> MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to
>>>> be a MADV_NOCORE option on FreeBSD.
>>>> 1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/
>>>>
>>>>
>>>
>>> Oh, right, so this would probably not compile on FreeBSD. Perhaps this
>>> function would have to be OS-specific after all (or call into an OS-specific
>>> madvise() after reserving the memory area).
>>>
>>
>> Is it just a differently named flag? If so, I think a single #ifdef macro
>> won't kill us in the common code.
>>
> Just the flag name is different.
> I should use RTE_EXEC_ENV_FREEBSD and RTE_EXEC_ENV_LINUX, right?

Yes, but we need this in two places, so a function call is still necessary.

> 
> Another question, in `eal_memalloc.c:alloc_seg`, I should undo the
> DONTMAP of the memory region.
> Right? @Anatoly

I don't think it's necessary. When you map different memory into that 
region, madvise() flags no longer apply. To be sure, i just tested this 
by adding another mmap() call after madvise() (in your test app) and 
remapping the same memory with MAP_FIXED, and the core dump was back to 
1GB of size. So, no, i don't think you should undo anything - the system 
does so automatically.

> 
> Just few minutes, I have prepared a patch for the OS-specific code:
> --- a/lib/librte_eal/common/eal_private.h
> +++ b/lib/librte_eal/common/eal_private.h
> @@ -443,4 +443,20 @@ rte_option_usage(void);
>   uint64_t
>   eal_get_baseaddr(void);
> 
> +/**
> + * @internal
> + * Exclude this pages from a core dump.
> + *
> + * @param addr
> + *  The memory region starts.
> + *
> + * @param len
> + *  The memory region length..
> + *
> + * @return
> + * returns 0 or -errno
> + */
> +int
> +eal_madvise_dontdump(void* addr, size_t len);
> +
>   #endif /* _EAL_PRIVATE_H_ */
> diff --git a/lib/librte_eal/freebsd/eal_memory.c
> b/lib/librte_eal/freebsd/eal_memory.c
> index a97d8f0f0..585042dde 100644
> --- a/lib/librte_eal/freebsd/eal_memory.c
> +++ b/lib/librte_eal/freebsd/eal_memory.c
> @@ -534,3 +534,9 @@ rte_eal_memseg_init(void)
>    memseg_primary_init() :
>    memseg_secondary_init();
>   }
> +
> +int
> +eal_madvise_dontdump(void* addr, size_t len)
> +{
> + return madvise(addr, len, MADV_NOCORE);
> +}
> diff --git a/lib/librte_eal/linux/eal_memory.c
> b/lib/librte_eal/linux/eal_memory.c
> index 7a9c97ff8..cfdbfccfe 100644
> --- a/lib/librte_eal/linux/eal_memory.c
> +++ b/lib/librte_eal/linux/eal_memory.c
> @@ -2479,3 +2479,9 @@ rte_eal_memseg_init(void)
>   #endif
>    memseg_secondary_init();
>   }
> +
> +int
> +eal_madvise_dontdump(void* addr, size_t len)
> +{
> + return madvise(addr, len, MADV_DONTDUMP);
> +}
> 

That would work as well (with added FreeBSD code of course), however if 
everyone else is OK with it, i'll settle for an #ifdef in common code.

-- 
Thanks,
Anatoly

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

* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory
  2020-04-24 11:00             ` Burakov, Anatoly
@ 2020-04-24 12:03               ` Li Feng
  0 siblings, 0 replies; 19+ messages in thread
From: Li Feng @ 2020-04-24 12:03 UTC (permalink / raw)
  To: Burakov, Anatoly
  Cc: Feng Li, Bruce Richardson, David Marchand, dev, Kyle Zhang, Yang Fan

Thanks,

Feng Li

Burakov, Anatoly <anatoly.burakov@intel.com> 于2020年4月24日周五 下午7:00写道:
>
> On 24-Apr-20 10:33 AM, Feng Li wrote:
> > Bruce Richardson <bruce.richardson@intel.com> 于2020年4月24日周五 下午5:14写道:
> >>
> >> On Fri, Apr 24, 2020 at 10:12:10AM +0100, Burakov, Anatoly wrote:
> >>> On 23-Apr-20 9:04 PM, David Marchand wrote:
> >>>> On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly
> >>>> <anatoly.burakov@intel.com> wrote:
> >>>>>> diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
> >>>>>> index cc7d54e0c..2d9564b28 100644
> >>>>>> --- a/lib/librte_eal/common/eal_common_memory.c
> >>>>>> +++ b/lib/librte_eal/common/eal_common_memory.c
> >>>>>> @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
> >>>>>>                 after_len = RTE_PTR_DIFF(map_end, aligned_end);
> >>>>>>                 if (after_len > 0)
> >>>>>>                         munmap(aligned_end, after_len);
> >>>>>> +
> >>>>>> +             /*
> >>>>>> +              * Exclude this pages from a core dump.
> >>>>>> +              */
> >>>>>> +             if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0)
> >>>>>> +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
> >>>>>> +                             strerror(errno));> +   } else {
> >>>>>> +             /*
> >>>>>> +              * Exclude this pages from a core dump.
> >>>>>> +              */
> >>>>>> +             if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0)
> >>>>>> +                     RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n",
> >>>>>> +                             strerror(errno));
> >>>>>>         }
> >>>>>>
> >>>>>>         return aligned_addr;
> >>>>>>
> >>>>>
> >>>>> For the contents of this patch,
> >>>>
> >>>> MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to
> >>>> be a MADV_NOCORE option on FreeBSD.
> >>>> 1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/
> >>>>
> >>>>
> >>>
> >>> Oh, right, so this would probably not compile on FreeBSD. Perhaps this
> >>> function would have to be OS-specific after all (or call into an OS-specific
> >>> madvise() after reserving the memory area).
> >>>
> >>
> >> Is it just a differently named flag? If so, I think a single #ifdef macro
> >> won't kill us in the common code.
> >>
> > Just the flag name is different.
> > I should use RTE_EXEC_ENV_FREEBSD and RTE_EXEC_ENV_LINUX, right?
>
> Yes, but we need this in two places, so a function call is still necessary.
>
> >
> > Another question, in `eal_memalloc.c:alloc_seg`, I should undo the
> > DONTMAP of the memory region.
> > Right? @Anatoly
>
> I don't think it's necessary. When you map different memory into that
> region, madvise() flags no longer apply. To be sure, i just tested this
> by adding another mmap() call after madvise() (in your test app) and
> remapping the same memory with MAP_FIXED, and the core dump was back to
> 1GB of size. So, no, i don't think you should undo anything - the system
> does so automatically.
Got it.
>
> >
> > Just few minutes, I have prepared a patch for the OS-specific code:
> > --- a/lib/librte_eal/common/eal_private.h
> > +++ b/lib/librte_eal/common/eal_private.h
> > @@ -443,4 +443,20 @@ rte_option_usage(void);
> >   uint64_t
> >   eal_get_baseaddr(void);
> >
> > +/**
> > + * @internal
> > + * Exclude this pages from a core dump.
> > + *
> > + * @param addr
> > + *  The memory region starts.
> > + *
> > + * @param len
> > + *  The memory region length..
> > + *
> > + * @return
> > + * returns 0 or -errno
> > + */
> > +int
> > +eal_madvise_dontdump(void* addr, size_t len);
> > +
> >   #endif /* _EAL_PRIVATE_H_ */
> > diff --git a/lib/librte_eal/freebsd/eal_memory.c
> > b/lib/librte_eal/freebsd/eal_memory.c
> > index a97d8f0f0..585042dde 100644
> > --- a/lib/librte_eal/freebsd/eal_memory.c
> > +++ b/lib/librte_eal/freebsd/eal_memory.c
> > @@ -534,3 +534,9 @@ rte_eal_memseg_init(void)
> >    memseg_primary_init() :
> >    memseg_secondary_init();
> >   }
> > +
> > +int
> > +eal_madvise_dontdump(void* addr, size_t len)
> > +{
> > + return madvise(addr, len, MADV_NOCORE);
> > +}
> > diff --git a/lib/librte_eal/linux/eal_memory.c
> > b/lib/librte_eal/linux/eal_memory.c
> > index 7a9c97ff8..cfdbfccfe 100644
> > --- a/lib/librte_eal/linux/eal_memory.c
> > +++ b/lib/librte_eal/linux/eal_memory.c
> > @@ -2479,3 +2479,9 @@ rte_eal_memseg_init(void)
> >   #endif
> >    memseg_secondary_init();
> >   }
> > +
> > +int
> > +eal_madvise_dontdump(void* addr, size_t len)
> > +{
> > + return madvise(addr, len, MADV_DONTDUMP);
> > +}
> >
>
> That would work as well (with added FreeBSD code of course), however if
> everyone else is OK with it, i'll settle for an #ifdef in common code.
>
> --
> Thanks,
> Anatoly

-- 
The SmartX email address is only for business purpose. Any sent message 
that is not related to the business is not authorized or permitted by 
SmartX.
本邮箱为北京志凌海纳科技有限公司(SmartX)工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权.



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

end of thread, other threads:[~2020-04-26 20:29 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200420070508.645533-1-fengli@smartx.com>
2020-04-20  7:07 ` [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory Li Feng
2020-04-20  7:13   ` David Marchand
2020-04-20  9:40     ` Feng Li
2020-04-21  7:41       ` David Marchand
2020-04-21 11:06         ` Feng Li
2020-04-21 12:19           ` Burakov, Anatoly
2020-04-21 16:38             ` Feng Li
2020-04-21 17:02               ` Burakov, Anatoly
2020-04-22  3:13                 ` Li Feng
2020-04-22  9:53                   ` Burakov, Anatoly
     [not found]                     ` <CAEK8JBCdfZJiKNjDNgC9nDGLni9Dvw+U1doRFnh+zkAs5TXEsg@mail.gmail.com>
2020-04-23 12:22                       ` Burakov, Anatoly
2020-04-23 15:43 ` [dpdk-dev] [PATCH v2] " Li Feng
2020-04-23 16:33   ` Burakov, Anatoly
2020-04-23 20:04     ` David Marchand
2020-04-24  9:12       ` Burakov, Anatoly
2020-04-24  9:14         ` Bruce Richardson
2020-04-24  9:33           ` Feng Li
2020-04-24 11:00             ` Burakov, Anatoly
2020-04-24 12:03               ` Li Feng

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