From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F329EA0C41 for ; Thu, 4 Nov 2021 09:39:12 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E5C834116D; Thu, 4 Nov 2021 09:39:12 +0100 (CET) Received: from smtpservice.6wind.com (host.78.145.23.62.rev.coltfrance.com [62.23.145.78]) by mails.dpdk.org (Postfix) with ESMTP id 4E3E140DFD; Thu, 4 Nov 2021 09:39:10 +0100 (CET) Received: from 6wind.com (unknown [10.16.18.213]) by smtpservice.6wind.com (Postfix) with ESMTP id 0EA1B6001B; Thu, 4 Nov 2021 09:39:10 +0100 (CET) Date: Thu, 4 Nov 2021 09:39:09 +0100 From: Olivier Matz To: David Marchand Cc: Anatoly Burakov , dev , Maxime Coquelin , dpdk stable Message-ID: References: <20211029095310.30785-1-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-stable] [PATCH] eal/memory: fix unused SIGBUS handler X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 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 Wed, Nov 03, 2021 at 09:03:19PM +0100, David Marchand wrote: > On Fri, Oct 29, 2021 at 11:53 AM Olivier Matz wrote: > > > > Since its introduction in 2018, the SIGBUS handler was never registered, > > and all related functions were unused. > > > > A SIGBUS can be received by the application when accessing to hugepages > > even if mmap() was successful, This happens especially when running > > inside containers when there is not enough hugepages. In this case, we > > need to recover. A similar scheme can be found in eal_memory.c. > > > > Fixes: 582bed1e1d1d ("mem: support mapping hugepages at runtime") > > Cc: stable@dpdk.org > > > > Signed-off-by: Olivier Matz > > This patch lgtm. > > The key point here is that in the "container context" (well, cgroups) > mmap succeeds regardless of availability of hugepages. > I would put an emphasis about this in the title. > > What do you think of: > mem: fix dynamic hugepage mapping in container Yes it's a better title.