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 C4046A04BB; Thu, 17 Sep 2020 16:17:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A391A1D673; Thu, 17 Sep 2020 16:17:21 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 714721D660; Thu, 17 Sep 2020 16:17:19 +0200 (CEST) IronPort-SDR: UfyPdp05NeCwsOAf6PitZIH0OrfxzQdMSv21WiFcRBMxlYUTOTLCu1BrylHScIDRCIJplfaDh+ aRcQ6bsTdZ+w== X-IronPort-AV: E=McAfee;i="6000,8403,9746"; a="177798302" X-IronPort-AV: E=Sophos;i="5.76,437,1592895600"; d="scan'208";a="177798302" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 07:17:17 -0700 IronPort-SDR: X1xQG6cL2l1iKLKmJSHuK3DEC2RJ8E7Gd+d4zESOHAA55dx3ZuX5aOJaxPTu4E6uCwZsSzxIzQ nH4PUlM0s0ow== X-IronPort-AV: E=Sophos;i="5.76,437,1592895600"; d="scan'208";a="452319795" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.206.43]) ([10.213.206.43]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 07:17:15 -0700 To: David Marchand Cc: dev , Maxime Coquelin , Sebastian Scheinkman , dpdk stable , Aaron Conole References: <20200910162407.12669-1-david.marchand@redhat.com> From: "Burakov, Anatoly" Message-ID: <41283b3a-5591-da2b-dea3-f069248d3265@intel.com> Date: Thu, 17 Sep 2020 15:17:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] eal/linux: fix memory allocations in containers+SELinux 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" On 17-Sep-20 2:47 PM, David Marchand wrote: > On Fri, Sep 11, 2020 at 2:46 PM Burakov, Anatoly > wrote: >>> Removing hugepage files is done in multiple places and the memory >>> allocation code is complex. >>> This fix tries to do the minimum and avoids touching other paths. >>> >>> If trying to remove the hugepage file before allocating a page fails, >>> the error is reported to the caller and the user will see a memory >>> allocation error log. >>> >>> Fixes: 582bed1e1d1d ("mem: support mapping hugepages at runtime") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: David Marchand >>> --- >> >> I believe only the primary will try to allocate new pages, but this only >> covers the page-per-file scenario. There's also legacy mem option (which >> would attempt to remove files prior to creating new ones - not sure if >> it's refused in that case), and single file segments option (which will >> mostly fallocate holes rather than delete files, but may still attempt >> to delete files - by the way, how does fallocate work with SELinux?). > > This issue should only concern part of the memory allocator that deals > with "named files" backed hugepages. > I would focus on the code relying on eal_get_hugefile_path() and I > agree I might have missed the legacy-mem part. > > For anonymous hugepages this should not matter. > > Anonymous hugepages shouldn't matter, yes, but single-file segments mode does fallocate() and remove - you have the remove part covered, but i'm just curious if fallocate() would also cause any issues with SELinux. -- Thanks, Anatoly