[dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory

[Bruce Richardson]

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