From: Feng Li <lifeng1519@gmail.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
David Marchand <david.marchand@redhat.com>,
Li Feng <fengli@smartx.com>, dev <dev@dpdk.org>,
Kyle Zhang <kyle@smartx.com>, Yang Fan <fanyang@smartx.com>
Subject: Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory
Date: Fri, 24 Apr 2020 17:33:55 +0800 [thread overview]
Message-ID: <CAEK8JBATc2S0-s7XekhiESEdy++idoQ6gksd491iY5ChNMGh2w@mail.gmail.com> (raw)
In-Reply-To: <20200424091421.GB1440@bricha3-MOBL.ger.corp.intel.com>
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);
+}
next prev parent reply other threads:[~2020-04-26 20:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200420070508.645533-1-fengli@smartx.com>
2020-04-20 7:07 ` [dpdk-dev] [PATCH] " 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 [this message]
2020-04-24 11:00 ` Burakov, Anatoly
2020-04-24 12:03 ` Li Feng
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=CAEK8JBATc2S0-s7XekhiESEdy++idoQ6gksd491iY5ChNMGh2w@mail.gmail.com \
--to=lifeng1519@gmail.com \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=fanyang@smartx.com \
--cc=fengli@smartx.com \
--cc=kyle@smartx.com \
/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).