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 85D26A0A02; Wed, 24 Mar 2021 19:01:39 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 41124140F92; Wed, 24 Mar 2021 19:01:39 +0100 (CET) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by mails.dpdk.org (Postfix) with ESMTP id CDFD6140F8F for ; Wed, 24 Mar 2021 19:01:37 +0100 (CET) Received: by mail-lf1-f51.google.com with SMTP id o126so23812467lfa.0 for ; Wed, 24 Mar 2021 11:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=SjU4kVa+lguWsVq/FOgfM/QGEhQVDFGRjQAUWsHHS7c=; b=l6Qu4l/0f8UCvLDwy88GuYtPBAChxWXZl2Pc8uYxYPdRCZt5hwKzTRoP5BY9EcXlr/ ncA2t3nBXvu0eCqrvpNUKbz0gQsBBFbD5v/fZMtX6zlBQb/O5OHdqxV2EAG0xlE3PBNM VmLL9oWXnEXAsfuB8sRTeXC8NY55M2IzKKzFPADFlk1yCWIoXGOsr0koatMmRM5WaCpX jpAhOHr7LT2r5hTorqkiHiTNcvpXFWWurT2ZfVJRgfl/V4C19jafC5KFo8Zx9yUIYKj7 4ELJY4jzf2CXinFnOErGwOCp6VCIzlKsn5P5NHhVw5x8ZbV7Bam0wesh/4TGl+pFG3zV 0ZwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=SjU4kVa+lguWsVq/FOgfM/QGEhQVDFGRjQAUWsHHS7c=; b=rrr/4/tXnoeSKB+SftF+v1UP8RAu/0L5SyYExBCAV+XNIu+9zsV4vHoj4fSI/lwpue iF2ntppJ9/Cr947btDqtMpGxAw0MkBx5AwtjIMS9WWMOxt1pg0OPT2IhBXsTZZ72GYgq E/cG8KX3v4W9OGJ+lLMppWZ0vPtnaoLGlGtGapXMp0kc1lcUm1IBSMhYGQiDY63HVfzL tHq1SDBw40KnCwF5UR6MUs6El4EOZOqdliSBctJgqK0zr7Of2rNGxaJ35q+yuEvVmto2 vXJPCPQCFUVG/JL6aAjTUykRv2Nuq2Wr30uQZyYEjF2Q+L0MxDhb6PKAd+91/3dsjp0M QYiQ== X-Gm-Message-State: AOAM531BmtLJ1YRPsqeYGTjga28a9i55X2vsae6EtzGnwnCoe5+htyau DQFfI3/Nn0njXwqYbjIC3u9RjMbjlnR99w== X-Google-Smtp-Source: ABdhPJzGUU1grvtHvaTUtJCb6nuN1ysDPbN7Mveq/kM31/ZTBSHgvomq6WLR6S0pm14CDSLriKkJ1g== X-Received: by 2002:ac2:47f4:: with SMTP id b20mr2522747lfp.524.1616608897083; Wed, 24 Mar 2021 11:01:37 -0700 (PDT) Received: from localhost.localdomain (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id q8sm291549lfn.286.2021.03.24.11.01.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Mar 2021 11:01:36 -0700 (PDT) From: Dmitry Kozlyuk To: dev@dpdk.org Cc: Dmitry Kozlyuk , Anatoly Burakov , Jie Zhou , David Marchand Date: Wed, 24 Mar 2021 21:01:28 +0300 Message-Id: <20210324180128.32752-1-dmitry.kozliuk@gmail.com> X-Mailer: git-send-email 2.29.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH] mem: fix cleanup on Windows X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" rte_mem_unmap() called from rte_eal_memory_detach() fails on Windows with message "EAL: Could not unmap memory: No error". This is because on Windows memory is not allocated using mapping. Confusing "No error" is caused by using errno instead of rte_errno set by rte_mem_unmap(). Multi-process is not supported on Windows and --in-memory is forced, so detaching memory is not needed on cleanup. Bypass the function in this case. Fix error handling to produce proper log message. Fixes: dfbc61a2f9a6 ("mem: detach memsegs on cleanup") Cc: Anatoly Burakov Reported-by: Jie Zhou Suggested-by: David Marchand Signed-off-by: Dmitry Kozlyuk --- lib/librte_eal/common/eal_common_memory.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c index 0e99986d3d..9ef9c65ac8 100644 --- a/lib/librte_eal/common/eal_common_memory.c +++ b/lib/librte_eal/common/eal_common_memory.c @@ -1010,6 +1010,13 @@ rte_eal_memory_detach(void) size_t page_sz = rte_mem_page_size(); unsigned int i; +#ifdef RTE_EXEC_ENV_WINDOWS + /* Multi-process is not supported, detaching is not needed. + * mcfg->mp_status can't be used: it's always "unknown" on Windows. + */ + return 0; +#endif + rte_rwlock_write_lock(&mcfg->memory_hotplug_lock); /* detach internal memory subsystem data first */ @@ -1032,7 +1039,7 @@ rte_eal_memory_detach(void) if (!msl->external) if (rte_mem_unmap(msl->base_va, msl->len) != 0) RTE_LOG(ERR, EAL, "Could not unmap memory: %s\n", - strerror(errno)); + rte_strerror(rte_errno)); /* * we are detaching the fbarray rather than destroying because -- 2.29.3