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 70B58A04B7; Thu, 17 Sep 2020 15:47:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 87FF21D664; Thu, 17 Sep 2020 15:47:43 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by dpdk.org (Postfix) with ESMTP id 4FC091D65E for ; Thu, 17 Sep 2020 15:47:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600350461; 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=z9AFQxA0rMWxVJgLHhKgZd8NkNJNN+rKW6cniFtjQUk=; b=AhDG7LpX9dQbGOrDCw8q28e3/J8WYCSNidFLhXVabHExIkadHRtd4WOnuDroACptTBSZjB J3mUXujKJgXoln1Pyt7g8+wXZNk4DM27XYp+NN9RaJ3OZbphG8FQQnvVia89K6avBXJIVT KSggmnY0D07ykuUaIOyQJVM7r30xJzc= Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-62-GrE5-hO1N9uH09b0UFAnoA-1; Thu, 17 Sep 2020 09:47:40 -0400 X-MC-Unique: GrE5-hO1N9uH09b0UFAnoA-1 Received: by mail-vs1-f71.google.com with SMTP id u206so516627vsc.15 for ; Thu, 17 Sep 2020 06:47:39 -0700 (PDT) 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; bh=z9AFQxA0rMWxVJgLHhKgZd8NkNJNN+rKW6cniFtjQUk=; b=NGteB2x1JZ/RBhHdR4xZRzOskqnOKxHhfnqSdyuc+nMktVyYWENuaMHSt51F61gF3Y +fpCC1vJdhnTPeCb+nyrcO2CI4YD5QyjunFaJJz6wFVvBlOzcAEEnyUDpwP4rij3pdST mqYzfJ5hiTzH4WBlfAhrvYkL/H1c1mxxbYMKZGyBndV5+7hTVBBhuumKTzGm5OnwBgtZ NGA03VByAvFmSskzqtPD12CoBm7F3YA+0J516i8yA2tB7NrzffOWfsUIzyDj/n1Cmueh qGXvaQtyM8nuTkRDa05P39mnhViNxXnTylzVROpPWW0AT2ZMhsmjWaXuXvzGAkdreC+w SlLg== X-Gm-Message-State: AOAM531rln3OZigNmfMXuiCigYZ7+5HnSvcTzDZd+iBbEzotQibBN4Sq qRqCCghIg/jI/LR9hiQRDqL1EijwN34156Zai/moGzRN8Kwowi3p0PtNNg/AK1sm7apFiPh83kX uKlxicBbiIVaJSo+IbU4= X-Received: by 2002:a67:fd44:: with SMTP id g4mr17923561vsr.18.1600350459479; Thu, 17 Sep 2020 06:47:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFQe2f1shPmMUBSJul+IAF4OfYutaXXzj6wN6lGxt+bmkXRg6RieL5rEEPpjQb5x2bJ0BvsndBG+h0ahdAFi4= X-Received: by 2002:a67:fd44:: with SMTP id g4mr17923548vsr.18.1600350459192; Thu, 17 Sep 2020 06:47:39 -0700 (PDT) MIME-Version: 1.0 References: <20200910162407.12669-1-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Thu, 17 Sep 2020 15:47:28 +0200 Message-ID: To: "Burakov, Anatoly" Cc: dev , Maxime Coquelin , Sebastian Scheinkman , dpdk stable , Aaron Conole Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 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. -- David Marchand