From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id BAEA55A3E for ; Fri, 1 Jun 2018 12:24:59 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2018 03:24:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,465,1520924400"; d="scan'208";a="43887307" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga007.fm.intel.com with ESMTP; 01 Jun 2018 03:24:58 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 1 Jun 2018 03:24:57 -0700 Received: from lcsmsx153.ger.corp.intel.com (10.186.165.228) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 1 Jun 2018 03:24:57 -0700 Received: from hasmsx105.ger.corp.intel.com ([169.254.1.132]) by LCSMSX153.ger.corp.intel.com ([169.254.8.83]) with mapi id 14.03.0319.002; Fri, 1 Jun 2018 13:24:54 +0300 From: "Stojaczyk, DariuszX" To: "dev@dpdk.org" , "Burakov, Anatoly" Thread-Topic: [PATCH v2 1/2] memalloc: do not leave unmapped holes in EAL virtual memory area Thread-Index: AQHT+Y7ZEt2aldHYakmnlSEENp1tB6RLL6FQ Date: Fri, 1 Jun 2018 10:24:54 +0000 Message-ID: References: <1527857469-159391-1-git-send-email-dariuszx.stojaczyk@intel.com> <1527860361-162114-1-git-send-email-dariuszx.stojaczyk@intel.com> In-Reply-To: <1527860361-162114-1-git-send-email-dariuszx.stojaczyk@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTM4NmYzNzMtYTBiOS00NzY1LTkzMTItNmI4N2FlZjVjMjk0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiI0aWtiT1wvY0VOanBSQ3Bnb0N5Q0NZeDVPXC9GdXdLZmwzc3U1cTZGMEVYSXFaa3VMTWhUZDBXSHdxdWI3dW41NDIifQ== x-ctpclassification: CTP_NT x-originating-ip: [10.103.103.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 1/2] memalloc: do not leave unmapped holes in EAL virtual memory area 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: , X-List-Received-Date: Fri, 01 Jun 2018 10:25:00 -0000 The Intel SMTP server keeps dying to me. It's really not fun trying to rese= nd these messages for half an hour without success. I'll resend this series= from my private mail in the evening. D. > -----Original Message----- > From: Stojaczyk, DariuszX > Sent: Friday, June 1, 2018 3:39 PM > To: dev@dpdk.org; Burakov, Anatoly > Cc: Stojaczyk, DariuszX > Subject: [PATCH v2 1/2] memalloc: do not leave unmapped holes in EAL > virtual memory area >=20 > EAL reserves a huge area in virtual address space to provide virtual addr= ess > contiguity for e.g. > future memory extensions (memory hotplug). During memory hotplug, if > the hugepage mmap succeeds but doesn't suffice EAL's requiriments, the > EAL would unmap this mapping straight away, leaving a hole in its virtual > memory area and making it available to everyone. As EAL still thinks it o= wns > the entire region, it may try to mmap it later with MAP_FIXED, possibly > overriding a user's mapping that was made in the meantime. >=20 > This patch ensures each hole is mapped back by EAL, so that it won't be > available to anyone else. >=20 > Changes from v1: > * checkpatch fixes >=20 > Signed-off-by: Dariusz Stojaczyk > --- > lib/librte_eal/linuxapp/eal/eal_memalloc.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) >=20 > diff --git a/lib/librte_eal/linuxapp/eal/eal_memalloc.c > b/lib/librte_eal/linuxapp/eal/eal_memalloc.c > index 8c11f98..2ab3d34 100644 > --- a/lib/librte_eal/linuxapp/eal/eal_memalloc.c > +++ b/lib/librte_eal/linuxapp/eal/eal_memalloc.c > @@ -39,6 +39,7 @@ > #include "eal_filesystem.h" > #include "eal_internal_cfg.h" > #include "eal_memalloc.h" > +#include "eal_private.h" >=20 > /* > * not all kernel version support fallocate on hugetlbfs, so fall back t= o @@ - > 490,6 +491,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int > socket_id, > int ret =3D 0; > int fd; > size_t alloc_sz; > + int flags; > + void *new_addr; >=20 > /* takes out a read lock on segment or segment list */ > fd =3D get_seg_fd(path, sizeof(path), hi, list_idx, seg_idx); @@ -585,6 > +588,20 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, >=20 > mapped: > munmap(addr, alloc_sz); > + flags =3D MAP_FIXED; > +#ifdef RTE_ARCH_PPC_64 > + flags |=3D MAP_HUGETLB; > +#endif > + new_addr =3D eal_get_virtual_area(addr, &alloc_sz, alloc_sz, 0, > flags); > + if (new_addr !=3D addr) { > + if (new_addr !=3D NULL) > + munmap(new_addr, alloc_sz); > + /* we're leaving a hole in our virtual address space. if > + * somebody else maps this hole now, we could accidentally > + * override it in the future. > + */ > + rte_panic("can't mmap holes in our virtual address space"); > + } > resized: > if (internal_config.single_file_segments) { > resize_hugefile(fd, path, list_idx, seg_idx, map_offset, > -- > 2.7.4