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 C4BA3A0032; Sat, 13 Nov 2021 18:23:02 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4DB5840691; Sat, 13 Nov 2021 18:23:02 +0100 (CET) Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by mails.dpdk.org (Postfix) with ESMTP id 0942E4013F for ; Sat, 13 Nov 2021 18:23:01 +0100 (CET) Received: by mail-pj1-f48.google.com with SMTP id y14-20020a17090a2b4e00b001a5824f4918so9686327pjc.4 for ; Sat, 13 Nov 2021 09:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ZpPO4OJUTboJdH6Lr5ZqJZKmAFcW9iFQ6rUyNWkvNV4=; b=3usdRcapC88G8zsPRGQgwvyYJQ7pd11wshqWAJWWbUkz8IUQS3yMBdinfm0axC9FS+ RSnid/zN6xH0SYXiXMAVdnLhTS7+bXWBb4xLopvEPUmR8AtEjOEnHRTeNTwudxaRx0PO fCcFw1UnbyLb3ZItfrY1ej0kaREzpiwvWshFrkSMTcFHGfbN3631Q9ihonoj7t7biBk5 iEUKSb2T45tOb3PVR4uCGIhE3TUE3uQzhsfVE0pklSGsc2xfHIOaJUPkvAdiPNr7Y+g8 CZGMRG4PddtlpzGH8NuwVBOjtE+JbGNlXMYkAOZK7QEsElp3qzNRrytGY3XdEWHy0vEW 46Og== 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=ZpPO4OJUTboJdH6Lr5ZqJZKmAFcW9iFQ6rUyNWkvNV4=; b=S+ruSMiCVigMVzozRcrsYE+h1BcruOS5edCZkiZCPMvMoOQHwRNWWc+E/vahMXHHq9 aEfcNhbMqhbGT6onE/GIbb4e4UC4DwwcuYH0bB9TkvJsuwgbuzKn4FV6Qyr6PM5IzRL0 4QoxmenGnaFCjdLRJFUFbz9n2Gcu9Uar4eyxOwJ7C5pliUyLS/jr1V+K2DtBZ2bqQ61A xi3BAVogdiEScZ6fLPhpLCTez2efDwHQzNoVlxRaWA6qLY+SyBtcXMx0s1AEMoPimpTs P7PpF1Ho0xUtREDRgf7rEqre+LsUntwgKW1KdGkf1AMm13TXldjMS8Eem7ACFfajmGK1 UsCA== X-Gm-Message-State: AOAM530gArd4IS4uacgz75lj6yiFJcaL7aNCVeVhcvo71EDGysQgubDZ LHRjFKylmkO/6T/rdu3p3/8XkPrwtdjisA== X-Google-Smtp-Source: ABdhPJzLKH6mXXExvGytOENDHS87w/nO/bXfEfhGJucCc/cs3g7iITYNtOQe6g170lI2ErkvEMJSkw== X-Received: by 2002:a17:902:748c:b0:141:c45e:c612 with SMTP id h12-20020a170902748c00b00141c45ec612mr18921490pll.73.1636824179708; Sat, 13 Nov 2021 09:22:59 -0800 (PST) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id u19sm9658370pfl.185.2021.11.13.09.22.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Nov 2021 09:22:58 -0800 (PST) From: Stephen Hemminger To: dev@dpdk.org Cc: Stephen Hemminger Subject: [PATCH v6 0/5] cleanup more resources on eal_cleanup Date: Sat, 13 Nov 2021 09:22:52 -0800 Message-Id: <20211113172257.6543-1-stephen@networkplumber.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20200428235827.15383-1-stephen@networkplumber.org> References: <20200428235827.15383-1-stephen@networkplumber.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 When testing using ASAN or valgrind with DPDK; there are lots of leftover memory and file descriptors. This makes it hard to find application leaks versus internal DPDK leaks. The DPDK has a function that applications can use to tell it to cleanup resources on shutdown (rte_eal_cleanup). But the current coverage of that API is spotty. Many internal parts of DPDK leave files and allocated memory behind. This patch set is a first step at getting the sub-parts of DPDK to cleanup after themselves. These are the easier ones, the harder and more critical ones are in the drivers and the memory subsystem. There should be no new exposed API or ABI changes here. v6 - fix windows stub v5 - add stub for windows build in rte_malloc cleanup v4 - rebase to 20.11-rc - drop one patch (alarm cleanup is implemented) - drop patch that ends worker threads on cleanup. the test is calling rte_exit/eal_cleanup in a forked process. (could argue this is a test bug)! Stephen Hemminger (5): eal: close log in eal_cleanup eal: mp: end the multiprocess thread during cleanup eal: vfio: cleanup the mp sync handle eal: hotplug: cleanup multiprocess resources eal: malloc: cleanup mp resources lib/eal/common/eal_common_log.c | 13 +++++++++++++ lib/eal/common/eal_common_proc.c | 20 +++++++++++++++++--- lib/eal/common/eal_private.h | 7 +++++++ lib/eal/common/hotplug_mp.c | 5 +++++ lib/eal/common/hotplug_mp.h | 6 ++++++ lib/eal/common/malloc_heap.c | 6 ++++++ lib/eal/common/malloc_heap.h | 3 +++ lib/eal/common/malloc_mp.c | 12 ++++++++++++ lib/eal/common/malloc_mp.h | 3 +++ lib/eal/linux/eal.c | 7 +++++++ lib/eal/linux/eal_log.c | 8 ++++++++ lib/eal/linux/eal_vfio.h | 1 + lib/eal/linux/eal_vfio_mp_sync.c | 8 ++++++++ lib/eal/windows/eal_mp.c | 7 +++++++ 14 files changed, 103 insertions(+), 3 deletions(-) -- 2.30.2