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 A1083A04C0; Thu, 17 Sep 2020 16:45:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E16581D67A; Thu, 17 Sep 2020 16:44:58 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id 0BA5D1D673 for ; Thu, 17 Sep 2020 16:44:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600353896; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dicp2eR+5KooGUsf8lsuQgmTsufhpv3eCG38d+Ohhs0=; b=gOQi9J3t1tS5S6qnK05JykQmXXvRzpuQvBFVkNeq9ocBCOzvbnHHiWiCGHYsTtF7JU4EKz fc/abRu4OZhRQo5uYd1A0sSgnG5bYTEFXtj/4IB2iP4ySq4uS7IwY015JtWQNx7lJUT+ni /43OiN26y8TWIJjGB5Wz3drucGNdxFs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-564-RZtjdoiTMIqLhOKGRQDRKA-1; Thu, 17 Sep 2020 10:44:54 -0400 X-MC-Unique: RZtjdoiTMIqLhOKGRQDRKA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 756E181CB07; Thu, 17 Sep 2020 14:44:53 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (ovpn-119-53.rdu2.redhat.com [10.10.119.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4021673663; Thu, 17 Sep 2020 14:44:45 +0000 (UTC) From: Aaron Conole To: "Burakov\, Anatoly" Cc: David Marchand , dev , Maxime Coquelin , Sebastian Scheinkman , dpdk stable References: <20200910162407.12669-1-david.marchand@redhat.com> <41283b3a-5591-da2b-dea3-f069248d3265@intel.com> Date: Thu, 17 Sep 2020 10:44:44 -0400 In-Reply-To: <41283b3a-5591-da2b-dea3-f069248d3265@intel.com> (Anatoly Burakov's message of "Thu, 17 Sep 2020 15:17:13 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=aconole@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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" "Burakov, Anatoly" writes: > 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. I think it might depend on the policy, file types, and labels allowed for the process. I did a little bit of digging but didn't find anything that specifically targets that call. I guess it may be something like: allow dom_t obj_t:file { getattr setattr appent ioctl lock open read write }; BUT that's just a guess without any real testing.