From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 3A72B1B04D; Thu, 12 Jul 2018 23:42:22 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CF8F322432; Thu, 12 Jul 2018 17:42:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 12 Jul 2018 17:42:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=xvV5aDLo40R23Eaqe4KVxC3a6i Bje1MOW2WTEfUUaaA=; b=A36yyJGHpD1ifLNdhGd6n3V1eh96+WnN6Dm1xzpKNc 3QZeXOMefCkoAuZefwEcgnlvwCwyfZ8UU1YCMDYMDeG4DtZe32VmDR5VbDaTkt0j qKe1uYkNeE2mRDEl5mRnOHGvzypzn2VaYyBBghc+eZIS6ie6yGczcl7RDuAAduU+ U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=xvV5aD Lo40R23Eaqe4KVxC3a6iBje1MOW2WTEfUUaaA=; b=qLHE8eVsKsGXZQuLdA/uzi 9yd4Q+fw2MzV6hq1C3A1vHfc6XpV6I5CJ+uIi2X/i61ZQ5eXvqxE5C6Y7CtQB1vH whgLfZc+XyG0s1YCyrv1boWK4RGd7e/qD0bgRAOtEDNWqPD/k5bssuSaqlxGQSS4 7B7qnaYUGUZZaY+nqDJeunU/4vxLwKCZf2DRHpDgJpka5dV9oJjNPe+MZIRuVOXS Doh9dqotX3Pr8KCf5jFX0J43WUuZcxomSrd4kIObEYFEF0Jm1zQ0GfphF+RovrE4 dAoJeBJ3YPdHI1KL4zfaHQF1dISpsMkSwSZtLB+Tp4KpHN6gbsqsnquuP0pbgelw == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 92E121025C; Thu, 12 Jul 2018 17:42:20 -0400 (EDT) From: Thomas Monjalon To: Dariusz Stojaczyk Cc: stable@dpdk.org, "Burakov, Anatoly" , dev@dpdk.org Date: Thu, 12 Jul 2018 23:42:19 +0200 Message-ID: <3545756.MiBi3UpLtl@xps> In-Reply-To: <5ab83fb6-47d0-d8ca-9efe-b6ac93f3217f@intel.com> References: <1527860361-162114-1-git-send-email-dariuszx.stojaczyk@intel.com> <1527857960-109306-1-git-send-email-dariuszx.stojaczyk@intel.com> <5ab83fb6-47d0-d8ca-9efe-b6ac93f3217f@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v3 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: Thu, 12 Jul 2018 21:42:22 -0000 01/06/2018 17:06, Burakov, Anatoly: > On 01-Jun-18 1:59 PM, Dariusz Stojaczyk wrote: > > EAL reserves a huge area in virtual address space > > to provide virtual address 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 owns 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. > > > > This patch ensures each hole is mapped back by EAL, > > so that it won't be available to anyone else. > > > > Changes from v2: > > * replaced rte_panic() with a CRIT log. > > * added "git fixline" tags > > > > Changes from v1: > > * checkpatch fixes > > > > Fixes: 582bed1e1d1d ("mem: support mapping hugepages at runtime") > > Cc: anatoly.burakov@intel.com > > Cc: stable@dpdk.org > > > > Signed-off-by: Dariusz Stojaczyk > > --- > > Acked-by: Anatoly Burakov > > Thomas, could you please fix the commit message on apply? Yes Applied, thanks