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 5C707A04B7 for ; Thu, 17 Sep 2020 15:47:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 496861C121; Thu, 17 Sep 2020 15:47:43 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by dpdk.org (Postfix) with ESMTP id 4B0621C121 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-vk1-f199.google.com (mail-vk1-f199.google.com [209.85.221.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-511-eiluuRzyNyGvMBwbVXD21g-1; Thu, 17 Sep 2020 09:47:40 -0400 X-MC-Unique: eiluuRzyNyGvMBwbVXD21g-1 Received: by mail-vk1-f199.google.com with SMTP id e2so516783vkn.11 for ; Thu, 17 Sep 2020 06:47:40 -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=q5DerWDBCL+EKSitUv++WfDz8uZyXm/Zra/SFXIMXDHsXAp0IHdl9LO0YOmo8uqXVu N/Rtd3rb2QTDKDKscYfYyg9O01wJHl9Chaj0Fyp9O86sUWnJdcwvrQGoHrxBkGDk9FgH M5U2S3Yv1EHP1qFfTZtONmo/j+cyQyYKwC+jJ9MR5oNCYB/hQ7TNR18KOQop9dllO4fj qhUaZG6ElH0mTlOGGctIp0kwc03c347ATrKtSMduLzqZ4mol26o1D2mR/icb68AnLH7u WE05pKg4fnFGIymJrVapif8aUDEjCwobxn8v4TisW/Dt2d89oEbhzl4bpoob6n+R6rVx GaNg== X-Gm-Message-State: AOAM530Ft03SZMXL/0DQL98r7nULadDT7Go+vxVY31mPg8nqgYBNeYqm OGeeTl6gMjkhmYP5prK/0jzvL4hYPdu66hZgupUCCPkDrwkRQIkq2SV0cQ9C4OuoFA35w4Ibsrm Fyb61k4dE7izGlVlKhHUEAP8= X-Received: by 2002:a67:fd44:: with SMTP id g4mr17923566vsr.18.1600350459493; 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-stable] [PATCH] eal/linux: fix memory allocations in containers+SELinux X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 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