From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E8FBCA00C2; Fri, 24 Apr 2020 14:37:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3E5FD1C1F7; Fri, 24 Apr 2020 14:37:42 +0200 (CEST) Received: from mail-ua1-f65.google.com (mail-ua1-f65.google.com [209.85.222.65]) by dpdk.org (Postfix) with ESMTP id 293361BF75 for ; Fri, 24 Apr 2020 14:37:39 +0200 (CEST) Received: by mail-ua1-f65.google.com with SMTP id a7so1302550uak.2 for ; Fri, 24 Apr 2020 05:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vj52uh+KI0yaR6Z+8gNuqoUKT26E6vqhz2jKPFO42yA=; b=zEeamSfkDFyO0WKHBE7pRZ2lOhxxXRUL9z2stANOhmp0j+yl9ShD90+vO18VV5+bJe thbyqVQ6PmFxnaYEzltf/AsK05A4c4qjr/uhYPkYehQR9L0LVKyqQIeHREysKU7uQCdF bcA/iSp5+IpmWkeGstZvQ8j0kHgrrTze1i2ZS0Up2ep9OTeN8LlixZ9E6XPwBQVNnOeV vsERQuY5ACbN2FRfvQw0WQNuGo05JZ1VUHX5Sy/664yVWD9CoTXbrp5pn6MrTT7kJC9O 2iWNcSqrWEowF58gl/oV82AS9KEgRDEOqLsgTCBfkURU1xXhKv37tfNGW6M5oUhhGLr1 01Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vj52uh+KI0yaR6Z+8gNuqoUKT26E6vqhz2jKPFO42yA=; b=UCTBYPrEr9XTIrB+LsINZvaFNSHk/trEVrvF46A60SHDtN+CK4Pma7wtGSJxfX9Ng2 eCvBOucmQA8lrdoj+DcCohuprqgzWzHIUQHEyj8FpMiTJyS7hgZ3mnOMX1EkpQ4sxvR4 JxwopDoqB1FzW/WmSd3jvYSDKwLYueIfy14PcehmZ6jj5gLgXlsxsw9tfztVO0Nq1PtO zo9QoTzORhCSewY3zg4mL635FiEHtafujZD0I1iftKavILOKH4suyipCjbALR11fRUgk suqPnjFNu3gUdNBOzO0dVZxqzrMj0BpbEf6Yai2AnzVAtS9eXt1feoix05jmMUckn6zZ Rfig== X-Gm-Message-State: AGi0PuajNNU+lep5yOa3k1oIJ7yVNxwcz3tqrOpsB7+eoXdTdkbvYXRJ z8ykBpi38jbDHNGhrIyldVYfX6Yp4uSKIZPYnpGwijJYvDD14Imcojf9hDWSmnrAQePi0JJ6rAP AKS463xpPEBIm X-Google-Smtp-Source: APiQypLwsmTUNfSRNqTcncpmJBE3Dox7nVVePk0meEQB+gFR7uSSWY+OwUzEA1BC9X5N5eA1aWPcvSBKg2+n4+s6aco= X-Received: by 2002:ab0:b13:: with SMTP id b19mr6904523uak.91.1587731858985; Fri, 24 Apr 2020 05:37:38 -0700 (PDT) MIME-Version: 1.0 References: <20200424105016.28974-1-fengli@smartx.com> <06c98fdc-9fc9-27b3-ebb9-e9a93f3a7561@intel.com> In-Reply-To: <06c98fdc-9fc9-27b3-ebb9-e9a93f3a7561@intel.com> From: Li Feng Date: Fri, 24 Apr 2020 20:37:27 +0800 Message-ID: To: "Burakov, Anatoly" Cc: dev , stable@dpdk.org, Kyle Zhang , Feng Li , Yang Fan , David Marchand , Bruce Richardson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v2] eal: use madvise to exclude unmapped memory from being dumped X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Thanks, Feng Li Burakov, Anatoly =E4=BA=8E2020=E5=B9=B44=E6=9C= =8824=E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=887:23=E5=86=99=E9=81=93= =EF=BC=9A > > On 24-Apr-20 11:50 AM, Li Feng wrote: > > 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 > > --- > > V2: > > - add support for freebsd. > > - when free_seg is called, mark the memory MADV_DONTDUMP. > > - when alloc_seg is called, mark the memory MADV_DODUMP. > > Isn't this v3 now? My mistake. I will using v4 for next version. > > > > > lib/librte_eal/common/eal_common_memory.c | 26 ++++++++++++++++++++++= ++++ > > lib/librte_eal/linux/eal_memalloc.c | 6 ++++++ > > 2 files changed, 32 insertions(+) > > > > diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal= /common/eal_common_memory.c > > index cc7d54e0c..83be94a20 100644 > > --- a/lib/librte_eal/common/eal_common_memory.c > > +++ b/lib/librte_eal/common/eal_common_memory.c > > @@ -177,6 +177,32 @@ eal_get_virtual_area(void *requested_addr, size_t = *size, > > after_len =3D RTE_PTR_DIFF(map_end, aligned_end); > > if (after_len > 0) > > munmap(aligned_end, after_len); > > + > > + /* > > + * Exclude this pages from a core dump. > > + */ > > +#ifdef RTE_EXEC_ENV_LINUX > > + if (madvise(aligned_addr, *size, MADV_DONTDUMP) !=3D 0) > > + RTE_LOG(DEBUG, EAL, "madvise failed: %s\n", > > + strerror(errno)); > > +#elif RTE_EXEC_ENV_FREEBSD > > + if (madvise(aligned_addr, *size, MADV_NOCORE) !=3D 0) > > + RTE_LOG(DEBUG, EAL, "madvise failed: %s\n", > > + strerror(errno)); > > +#endif > > + } else { > > + /* > > + * Exclude this pages from a core dump. > > + */ > > +#ifdef RTE_EXEC_ENV_LINUX > > + if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) !=3D 0) > > + RTE_LOG(DEBUG, EAL, "madvise failed: %s\n", > > + strerror(errno)); > > +#elif RTE_EXEC_ENV_FREEBSD > > + if (madvise(mapped_addr, map_sz, MADV_NOCORE) !=3D 0) > > + RTE_LOG(DEBUG, EAL, "madvise failed: %s\n", > > + strerror(errno)); > > +#endif > > } > > DRY (Don't Repeat Yourself) :) Probably easier to do "if (!unmap) ..." > than putting this into two places. OK. I put this into two places, because the size is more accurate in this p= lace. > > > > > return aligned_addr; > > diff --git a/lib/librte_eal/linux/eal_memalloc.c b/lib/librte_eal/linux= /eal_memalloc.c > > index af6d0d023..9d2a6fc6f 100644 > > --- a/lib/librte_eal/linux/eal_memalloc.c > > +++ b/lib/librte_eal/linux/eal_memalloc.c > > @@ -571,6 +571,9 @@ alloc_seg(struct rte_memseg *ms, void *addr, int so= cket_id, > > goto resized; > > } > > > > + if (madvise(addr, alloc_sz, MADV_DODUMP) !=3D 0) > > + RTE_LOG(DEBUG, EAL, "madvise failed: %s\n", strerror(errn= o)); > > + > > See discussion for v2, i believe this is unnecessary. > > > /* In linux, hugetlb limitations, like cgroup, are > > * enforced at fault time instead of mmap(), even > > * with the option of MAP_POPULATE. Kernel will send > > @@ -687,6 +690,9 @@ free_seg(struct rte_memseg *ms, struct hugepage_inf= o *hi, > > return -1; > > } > > > > + if (madvise(ms->addr, ms->len, MADV_DONTDUMP) !=3D 0) > > + RTE_LOG(DEBUG, EAL, "madvise failed: %s\n", strerror(errn= o)); > > + > > exit_early =3D false; > > > > /* if we're using anonymous hugepages, nothing to be done */ > > > > > -- > Thanks, > Anatoly --=20 The SmartX email address is only for business purpose. Any sent message=20 that is not related to the business is not authorized or permitted by=20 SmartX. =E6=9C=AC=E9=82=AE=E7=AE=B1=E4=B8=BA=E5=8C=97=E4=BA=AC=E5=BF=97=E5=87=8C=E6= =B5=B7=E7=BA=B3=E7=A7=91=E6=8A=80=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8=EF=BC= =88SmartX=EF=BC=89=E5=B7=A5=E4=BD=9C=E9=82=AE=E7=AE=B1. =E5=A6=82=E6=9C=AC= =E9=82=AE=E7=AE=B1=E5=8F=91=E5=87=BA=E7=9A=84=E9=82=AE=E4=BB=B6=E4=B8=8E=E5= =B7=A5=E4=BD=9C=E6=97=A0=E5=85=B3,=E8=AF=A5=E9=82=AE=E4=BB=B6=E6=9C=AA=E5= =BE=97=E5=88=B0=E6=9C=AC=E5=85=AC=E5=8F=B8=E4=BB=BB=E4=BD=95=E7=9A=84=E6=98= =8E=E7=A4=BA=E6=88=96=E9=BB=98=E7=A4=BA=E7=9A=84=E6=8E=88=E6=9D=83.