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 41294A0A0E for ; Mon, 10 May 2021 18:15:55 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 345AF40395; Mon, 10 May 2021 18:15:55 +0200 (CEST) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2070.outbound.protection.outlook.com [40.107.102.70]) by mails.dpdk.org (Postfix) with ESMTP id 247B840395 for ; Mon, 10 May 2021 18:15:54 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jRwEgLVclMOEnSyyDl9AT6/30AWyodpzTFZzX2LGQtQfuHi7Sq+F9mTzdp071nm+AtyVXwS0aHBoaCDTNZ+/mjoYO9Rz3CpOVrtvsjpKEieQKeKkcIkJsl1IXRII61/B5Cn9qcHgSHRD4zbKWOmqGcv9JOrrosVD6HWmYZxh1U0mtZN2TgEc83vBpV1bYwp5d6L/W7PGJ2sMIMTyEkY9hQmMJKj4N2oH3lIK3MheXheGgbLZs12Cczr9FJLXMxO8DXP76+vO1EEYXyS3fucUBn8EW2A5L5pJa0qDaW2Je6Fsqh/3eFLmATS46fklrP4qGsWr+4dY2i/1Faa4GfiQKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p0bpV4QynFYk4b8I6oHSAu0KP+h7QXSujLYnyWAQvzE=; b=EKXaNy1wrT8jvS0vKWUlnjy0tnr9f2bjjohDgyBIDIDbtYMuu4bstDjvwf5+JJlVzk20LN/NoVPZgbLvqJaq1IDZyDJVI+hFn6s94bIlFg1Q8Yamg55SI8BwpfPHt741wCnr7HOVh61vXQd0NrrS+DB5+8h2MwbRaOyYSwH7OQN8t3w2KztmzzxSQ/GjhcZYsJlKilx1JdeJCXtSi6M8Se2DCDD/md5fPiHh/bTNWmSxCVw0PkGe+J4G054jzxb5a45CleKwQy45YqpyI1vigsoKjoi5Ih26J0CO2XbM3+huL0wkzHgJENQIr96g5zLxwuxcnJSpe5T7Zxbe7zZBdw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.112.34) smtp.rcpttodomain=intel.com smtp.mailfrom=nvidia.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p0bpV4QynFYk4b8I6oHSAu0KP+h7QXSujLYnyWAQvzE=; b=GYknofeYyCQSGUI9v8T1utZp/csySPGv1ds9HjDufbbsM5YskFtfO2p1fVPg0liPVLbJU/fQHkuq7DaGWwHir1ukRn33SqtJMKBE82I7zeA8i9zl59LooVmzw1ZjXisYEITEd+0XAkzukx5NscD3p4BLxPAiYDyywAO/VPooTmOLO/52bgddghsJXE16lXLAGD/fTS5uWsX/c/qEWpW6no+vGoAQHfXTQ5oy3EkO/gF4keQ1uAhla+hGCXAU04uhKo7O6LQWcJqIX7HeaowujcJ5nBIWquxpm5AHkEpJCjgIKLhxJ6xNtcXqu0C9cp9WBcLtDZhX43WxKqHLz/e0Aw== Received: from DM5PR11CA0018.namprd11.prod.outlook.com (2603:10b6:3:115::28) by CY4PR1201MB0021.namprd12.prod.outlook.com (2603:10b6:910:1a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.28; Mon, 10 May 2021 16:15:52 +0000 Received: from DM6NAM11FT058.eop-nam11.prod.protection.outlook.com (2603:10b6:3:115:cafe::58) by DM5PR11CA0018.outlook.office365.com (2603:10b6:3:115::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.24 via Frontend Transport; Mon, 10 May 2021 16:15:52 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.112.34) smtp.mailfrom=nvidia.com; intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.112.34 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.112.34; helo=mail.nvidia.com; Received: from mail.nvidia.com (216.228.112.34) by DM6NAM11FT058.mail.protection.outlook.com (10.13.172.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4108.25 via Frontend Transport; Mon, 10 May 2021 16:15:52 +0000 Received: from nvidia.com (172.20.145.6) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 10 May 2021 16:15:50 +0000 From: Xueming Li To: Roy Shterman CC: Luca Boccassi , Anatoly Burakov , dpdk stable Date: Tue, 11 May 2021 00:01:17 +0800 Message-ID: <20210510160258.30982-128-xuemingl@nvidia.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210510160258.30982-1-xuemingl@nvidia.com> References: <20210510160258.30982-1-xuemingl@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [172.20.145.6] X-ClientProxiedBy: HQMAIL111.nvidia.com (172.20.187.18) To HQMAIL107.nvidia.com (172.20.187.13) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 501c8204-af06-43a8-6892-08d913cee226 X-MS-TrafficTypeDiagnostic: CY4PR1201MB0021: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 22RsEDlSqlij44qIL3DhSSYuuQ8AFnOkjTnp/RB7Di8MQRfmTYhepnI1PfJDtMKzLUEgPAPNFZbXGAc4yI8y1bmPo6X/jzvI3kLpg7bhhU4HHaoP4DojM4TYFSPw5EbTevzTcusCArp6h90BU1DoHS+ZwS4RxP6tB6x2ZbZ7Ch5y/qqutktCzTcnftibDs9qM/2wAONfo+/QOv5V2jvyUeNHoiYrMxkL3RETKG1bhrCEtFQqX4MPVysQqKSNVnB7/FWcKC6WOFme8hjVBM24ETxTZKjKZLKSur7p9oDojMP5SvfUigxQqoakHg3XLzm8dgXzS3eXP91uZ4StAw+GQq0SII6R/nWPsyJHY7qIfzogyiM6n4oJxJfR6zXCu6cnFNluDsd4ZwBYlVsgajBIJHD072IyLRdVvmFuPInKANA2cwYYCTcC14CwxAcK75qH5Ab/ArsgQD9w0MXcSymGhbsjDphdPV7XoEP1BZFBD/+MPmky/DSf8ZzOcusFVUtAXtPzz7q1qOK5yoekS69CM2XCbzg1z/MvABJO6Vk6alyY+yVzdF7c9/pwiJFU6JULmT+Bw9ak5+Cs00cjV/MUtuUs3VRib/OrLngZoOlOM9hoz3ojLsxD6z2MEp6jUgivPesKcTS/lTl5SCENq5EGKrUhXFB5HbfmQzD2m47wLr7X/3T8wY5msgAqx3C9GU39bGm8QyzdnejyF6JY7sl1348NoZX+Xi+MhCz734deOU/xDmJJHS+LIKFcxjwkkO3dKffU34mB/UEW2nMEI6ML8sjYC2thCnd7GYRDYb4BhV0= X-Forefront-Antispam-Report: CIP:216.228.112.34; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.nvidia.com; PTR:schybrid03.nvidia.com; CAT:NONE; SFS:(4636009)(136003)(39860400002)(376002)(346002)(396003)(46966006)(36840700001)(82310400003)(70206006)(966005)(36860700001)(54906003)(7696005)(1076003)(2616005)(16526019)(55016002)(426003)(83380400001)(70586007)(5660300002)(36756003)(478600001)(186003)(6916009)(82740400003)(2906002)(8936002)(36906005)(86362001)(336012)(53546011)(316002)(26005)(6286002)(6666004)(7636003)(8676002)(4326008)(47076005)(356005)(14583001); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2021 16:15:52.6825 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 501c8204-af06-43a8-6892-08d913cee226 X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a; Ip=[216.228.112.34]; Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT058.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1201MB0021 Subject: [dpdk-stable] patch 'mem: fix freeing segments in --huge-unlink mode' has been queued to stable release 20.11.2 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" Hi, FYI, your patch has been queued to stable release 20.11.2 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 05/12/21. 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/steevenlee/dpdk This queued commit can be viewed at: https://github.com/steevenlee/dpdk/commit/e0a41b8c471b32fc855bcd016d97bbb935fd36b0 Thanks. Xueming Li --- >From e0a41b8c471b32fc855bcd016d97bbb935fd36b0 Mon Sep 17 00:00:00 2001 From: Roy Shterman Date: Mon, 22 Feb 2021 12:41:31 +0200 Subject: [PATCH] mem: fix freeing segments in --huge-unlink mode Cc: Luca Boccassi [ upstream commit edf20bd8a55192616e4a0f26c346b55ddbac1d81 ] When using huge_unlink we unlink the segment right after allocation. Although we unlink the file we keep the fd in fd_list so file still exist just the path deleted. When freeing the hugepage we need to close the fd and assign it with (-1) in fd_list for the page to be released. The current flow fails rte_malloc in the following flow when working with --huge-unlink option: 1. alloc_seg() for segment A - We allocate a segment, unlink the path to the segment and keep the file descriptor in fd_list. 2. free_seg() for segment A - We clear the segment metadata and return - without closing fd or assigning (-1) in fd list. 3. alloc_seg() for segment A again - We find segment A as available, try to allocate it, find the old fd in fd_list try to unlink it as part of alloc_seg() but failed because path doesn't exist. The impact of such error is falsely failing rte_malloc() although we have hugepages available. Fixes: d435aad37da7 ("mem: support --huge-unlink mode") Signed-off-by: Roy Shterman Acked-by: Anatoly Burakov --- lib/librte_eal/linux/eal_memalloc.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/lib/librte_eal/linux/eal_memalloc.c b/lib/librte_eal/linux/eal_memalloc.c index 6dc1b2baec..c590d60430 100644 --- a/lib/librte_eal/linux/eal_memalloc.c +++ b/lib/librte_eal/linux/eal_memalloc.c @@ -709,7 +709,6 @@ free_seg(struct rte_memseg *ms, struct hugepage_info *hi, uint64_t map_offset; char path[PATH_MAX]; int fd, ret = 0; - bool exit_early; const struct internal_config *internal_conf = eal_get_internal_configuration(); @@ -725,17 +724,8 @@ free_seg(struct rte_memseg *ms, struct hugepage_info *hi, eal_mem_set_dump(ms->addr, ms->len, false); - exit_early = false; - /* if we're using anonymous hugepages, nothing to be done */ - if (internal_conf->in_memory && !memfd_create_supported) - exit_early = true; - - /* if we've already unlinked the page, nothing needs to be done */ - if (!internal_conf->in_memory && internal_conf->hugepage_unlink) - exit_early = true; - - if (exit_early) { + if (internal_conf->in_memory && !memfd_create_supported) { memset(ms, 0, sizeof(*ms)); return 0; } @@ -761,7 +751,7 @@ free_seg(struct rte_memseg *ms, struct hugepage_info *hi, /* if we're able to take out a write lock, we're the last one * holding onto this page. */ - if (!internal_conf->in_memory) { + if (!internal_conf->in_memory && !internal_conf->hugepage_unlink) { ret = lock(fd, LOCK_EX); if (ret >= 0) { /* no one else is using this page */ -- 2.25.1 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2021-05-10 23:59:29.914004700 +0800 +++ 0129-mem-fix-freeing-segments-in-huge-unlink-mode.patch 2021-05-10 23:59:26.530000000 +0800 @@ -1 +1 @@ -From edf20bd8a55192616e4a0f26c346b55ddbac1d81 Mon Sep 17 00:00:00 2001 +From e0a41b8c471b32fc855bcd016d97bbb935fd36b0 Mon Sep 17 00:00:00 2001 @@ -4,0 +5,3 @@ +Cc: Luca Boccassi + +[ upstream commit edf20bd8a55192616e4a0f26c346b55ddbac1d81 ] @@ -29 +31,0 @@ -Cc: stable@dpdk.org @@ -38 +40 @@ -index 00e2662c15..0ec8542283 100644 +index 6dc1b2baec..c590d60430 100644