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 CEB4CA0C41 for ; Tue, 30 Nov 2021 17:41:47 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C5B52410F7; Tue, 30 Nov 2021 17:41:47 +0100 (CET) Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by mails.dpdk.org (Postfix) with ESMTP id A21DF410F7 for ; Tue, 30 Nov 2021 17:41:46 +0100 (CET) Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 0401E3F044 for ; Tue, 30 Nov 2021 16:41:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1638290505; bh=Nquj1FOijuW71wrGyG4BmdQpz5Z387W54HZyXYSoRs8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=ayIp6qU43G9SWFU119FZJx0LFniX266es01iLfLWEdSzCXJ+d961Kbz58gx2cGXXo P/H2rpiqjR8d9JbLSb6OPeyXLc1TT4Ct3RbSp37Bja2VK4Ki0y/vssZzvuqM80L/1q pSJCXd7+jclnaAYEFW/IhBhlSqQ38WpGwrYolnw/n3Npxp/AJYFPXRQMLy0cfvYnl+ mZQsrnW8rHR22Tnzis1wyRpV6IWqbnMk4iWV+gjWbRZI1TqUsrMGjQvhRzdYvYqQL4 MacRobhCY42rvATOIQyTORiolYdwCZ2uHjkAZcbDNJheuBCsf5SWC41Tz6a1dURarC M/ipluYDiT7Nw== Received: by mail-ed1-f70.google.com with SMTP id w18-20020a056402071200b003e61cbafdb4so17489360edx.4 for ; Tue, 30 Nov 2021 08:41:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Nquj1FOijuW71wrGyG4BmdQpz5Z387W54HZyXYSoRs8=; b=z44XEDbkjO8Y7FmtWAZWeNQdV7h32OARszGiueX28qh1kmgjthoe/c3gnVoGgfyB2M BE3T84juaGpwaBkJ+1GG4AXfMgbtBHJgboXcLfn5VXwTu/0d6Z8SAf5Ng0LwbDF8PUQ2 DPp2tfoE6P5Hh0/lCcOMpsWaYJfuvnTco88Z4quc45rfpd4aViCtj7oXa2d7/+UlzoVM /mZugISKn6YbEiAwgr90mo2OyycKsVHW6VEXP0xjkIJPIosr+L78gvtJJ3TTP+nurTdR WLfmGKho/dc2DCKV7cexbxW7iJCzSRsq2mmdn9tE+L6bQ4Dnn8cvDaJ3EYCc5/skdpTb OEag== X-Gm-Message-State: AOAM532gZkiUA/jcUcBamkfmuvuy7CFSay1/zfQjO0KAHkjVXpn85UyU aI0gZfB1yi1hI+pfkV1sgvtiueDCbgAyDty+9JFj2wXpMYyW6TtLNIaVOJOJnjUnjip4wOTlrlZ OjOgDaWh3Od3RrM8jvF8+iEFO X-Received: by 2002:a05:6402:2756:: with SMTP id z22mr127373edd.200.1638290504399; Tue, 30 Nov 2021 08:41:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJz/UkXJ/bxkHBfVdyfM8gXLWsn68iWITekrbKzc4Ft66lf/p2M2hrwjYSS4OrDifEM8cREpUw== X-Received: by 2002:a05:6402:2756:: with SMTP id z22mr127346edd.200.1638290504239; Tue, 30 Nov 2021 08:41:44 -0800 (PST) Received: from localhost.localdomain ([2001:67c:1560:8007::aac:c4ad]) by smtp.gmail.com with ESMTPSA id mp9sm9690411ejc.106.2021.11.30.08.41.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Nov 2021 08:41:43 -0800 (PST) From: christian.ehrhardt@canonical.com To: Olivier Matz Cc: Maxime Coquelin , David Marchand , dpdk stable Subject: patch 'mem: fix dynamic hugepage mapping in container' has been queued to stable release 19.11.11 Date: Tue, 30 Nov 2021 17:35:14 +0100 Message-Id: <20211130163605.2460997-110-christian.ehrhardt@canonical.com> X-Mailer: git-send-email 2.34.0 In-Reply-To: <20211130163605.2460997-1-christian.ehrhardt@canonical.com> References: <20211130163605.2460997-1-christian.ehrhardt@canonical.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Hi, FYI, your patch has been queued to stable release 19.11.11 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before December 10th 2021. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Queued patches are on a temporary branch at: https://github.com/cpaelzer/dpdk-stable-queue This queued commit can be viewed at: https://github.com/cpaelzer/dpdk-stable-queue/commit/480955dbb4f0a7718ef253ff0eb0e01bd9ba6beb Thanks. Christian Ehrhardt --- >From 480955dbb4f0a7718ef253ff0eb0e01bd9ba6beb Mon Sep 17 00:00:00 2001 From: Olivier Matz Date: Fri, 29 Oct 2021 11:53:10 +0200 Subject: [PATCH] mem: fix dynamic hugepage mapping in container [ upstream commit 9bffc92850e8524474eebe2d559d09bdf3f0b96b ] 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") Signed-off-by: Olivier Matz Reviewed-by: Maxime Coquelin Acked-by: David Marchand --- lib/librte_eal/linux/eal/eal_memalloc.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/linux/eal/eal_memalloc.c index e8b2daa66a..9f2d3e113c 100644 --- a/lib/librte_eal/linux/eal/eal_memalloc.c +++ b/lib/librte_eal/linux/eal/eal_memalloc.c @@ -107,7 +107,7 @@ static struct rte_memseg_list local_memsegs[RTE_MAX_MEMSEG_LISTS]; static sigjmp_buf huge_jmpenv; -static void __rte_unused huge_sigbus_handler(int signo __rte_unused) +static void huge_sigbus_handler(int signo __rte_unused) { siglongjmp(huge_jmpenv, 1); } @@ -116,7 +116,7 @@ static void __rte_unused huge_sigbus_handler(int signo __rte_unused) * non-static local variable in the stack frame calling sigsetjmp might be * clobbered by a call to longjmp. */ -static int __rte_unused huge_wrap_sigsetjmp(void) +static int huge_wrap_sigsetjmp(void) { return sigsetjmp(huge_jmpenv, 1); } @@ -124,7 +124,7 @@ static int __rte_unused huge_wrap_sigsetjmp(void) static struct sigaction huge_action_old; static int huge_need_recover; -static void __rte_unused +static void huge_register_sigbus(void) { sigset_t mask; @@ -139,7 +139,7 @@ huge_register_sigbus(void) huge_need_recover = !sigaction(SIGBUS, &action, &huge_action_old); } -static void __rte_unused +static void huge_recover_sigbus(void) { if (huge_need_recover) { @@ -565,6 +565,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, mmap_flags = MAP_SHARED | MAP_POPULATE | MAP_FIXED; } + huge_register_sigbus(); + /* * map the segment, and populate page tables, the kernel fills * this segment with zeros if it's a new page. @@ -640,6 +642,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, __func__); #endif + huge_recover_sigbus(); + ms->addr = addr; ms->hugepage_sz = alloc_sz; ms->len = alloc_sz; @@ -653,6 +657,7 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, mapped: munmap(addr, alloc_sz); unmapped: + huge_recover_sigbus(); flags = MAP_FIXED; new_addr = eal_get_virtual_area(addr, &alloc_sz, alloc_sz, 0, flags); if (new_addr != addr) { -- 2.34.0 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2021-11-30 16:50:12.204664093 +0100 +++ 0110-mem-fix-dynamic-hugepage-mapping-in-container.patch 2021-11-30 16:50:05.914874440 +0100 @@ -1 +1 @@ -From 9bffc92850e8524474eebe2d559d09bdf3f0b96b Mon Sep 17 00:00:00 2001 +From 480955dbb4f0a7718ef253ff0eb0e01bd9ba6beb Mon Sep 17 00:00:00 2001 @@ -5,0 +6,2 @@ +[ upstream commit 9bffc92850e8524474eebe2d559d09bdf3f0b96b ] + @@ -15 +16,0 @@ -Cc: stable@dpdk.org @@ -21 +22 @@ - lib/eal/linux/eal_memalloc.c | 13 +++++++++---- + lib/librte_eal/linux/eal/eal_memalloc.c | 13 +++++++++---- @@ -24,4 +25,4 @@ -diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c -index 0ec8542283..337f2bc739 100644 ---- a/lib/eal/linux/eal_memalloc.c -+++ b/lib/eal/linux/eal_memalloc.c +diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/linux/eal/eal_memalloc.c +index e8b2daa66a..9f2d3e113c 100644 +--- a/lib/librte_eal/linux/eal/eal_memalloc.c ++++ b/lib/librte_eal/linux/eal/eal_memalloc.c @@ -64 +65 @@ -@@ -576,6 +576,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, +@@ -565,6 +565,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, @@ -73 +74 @@ -@@ -651,6 +653,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, +@@ -640,6 +642,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, @@ -82 +83 @@ -@@ -664,6 +668,7 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, +@@ -653,6 +657,7 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, @@ -87 +88 @@ - flags = EAL_RESERVE_FORCE_ADDRESS; + flags = MAP_FIXED;