From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id A3678A051C for ; Tue, 11 Feb 2020 12:30:40 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9AFE42BE9; Tue, 11 Feb 2020 12:30:40 +0100 (CET) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 233D21BF9F for ; Tue, 11 Feb 2020 12:30:39 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id y17so11891999wrh.5 for ; Tue, 11 Feb 2020 03:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=vfEIWCEVPWDc9THX65kArXc6dZJArYhiXtWO8nBHbQg=; b=WhBrMBoW67OtWgfZ5jGC0bhNJHWJX8QVHELLOEkyR9m7VDQPqTq3vb20J4X2xpxXUX DmAQhmreJ5tnMdsUwMCy3VId9byChf0FylDyuRdeD/eN/nXr0XT3fs5ty8XCQCBg2Frs nwWsJjB0qEgPvC3LkQ5MmG2F3km/kmvK7BfkJUVgKEHBLjIILvoGXmsimkq0QVIO+/xl zSGNReWtjJxwKCvBSJyY8WzjzJu85J90Jo3SzTxUFBoyECqOPp7McBSX0PoAbhcmsYL/ CjGjHnU7ocsiv02GeOGm5cT8DW+SAK50Ydcl/1aXgYP6WGS2AgSk22vEebXT66fq0L7t 9jew== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=vfEIWCEVPWDc9THX65kArXc6dZJArYhiXtWO8nBHbQg=; b=PgRoErRGMQYR8b0kWmIYsmuDm2s8Ecohez6EHOTR8uGyB+6L5HeeGPZevd5uT50nci neYbY484uqc4HLy12qamEHh/4+O7x0nI/qc20n6Au/nM9mw2GykGloDm1kqzTH6BnbBh lkNO82ip7YTWx8y6oddRwZ/7GAQv6O52EpQfBcFRDqTn1MQof0wy+oSYnIFuyN1S1bGa NsgVJ/86XWxSVYw8h17U16oJmS/SmBxOi1nxRdLk+bkPXXFgT+MqnvF2otWuS6qpOKdV L7vJ7cxG+tUA6psEvun/deRd/hFAuhRKFhn89xr32p1IFc4JzfU24KiCTXSE84XTYVAr frvQ== X-Gm-Message-State: APjAAAVg34W8MfjZt3f5FzEq67Toul5gY0N1Lk6O49IdUGPr3+tVPx+w OM6qnM9KQenF5bdUEMwAQt8= X-Google-Smtp-Source: APXvYqwf2OQf8rcDGEpzxLVkUo9VZdJeNmy3kCAdSnRMy2I6Xj2l6TudQ+S8RAtcJ0aauLlGoOGRgg== X-Received: by 2002:adf:f886:: with SMTP id u6mr8178451wrp.409.1581420638831; Tue, 11 Feb 2020 03:30:38 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id l15sm4871258wrv.39.2020.02.11.03.30.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2020 03:30:38 -0800 (PST) From: luca.boccassi@gmail.com To: Olivier Matz Cc: Anatoly Burakov , Alvin Zhang , dpdk stable Date: Tue, 11 Feb 2020 11:21:00 +0000 Message-Id: <20200211112216.3929-114-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200211112216.3929-1-luca.boccassi@gmail.com> References: <20200211112216.3929-1-luca.boccassi@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'mempool: fix populate with small virtual chunks' has been queued to stable release 19.11.1 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 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 19.11.1 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 02/13/20. 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. Thanks. Luca Boccassi --- >From 68481604c1baa5e23731bc381930e650bc60c7c5 Mon Sep 17 00:00:00 2001 From: Olivier Matz Date: Fri, 17 Jan 2020 15:57:52 +0100 Subject: [PATCH] mempool: fix populate with small virtual chunks [ upstream commit 43503c59adee6cae7069da23e105c24e044bf72c ] To populate a mempool with a virtual area, the mempool code calls rte_mempool_populate_iova() for each iova-contiguous area. It happens (rarely) that this area is too small to store one object. In this case, rte_mempool_populate_iova() returns an error, which is forwarded by rte_mempool_populate_virt(). This case should not throw an error in rte_mempool_populate_virt(). Instead, the area that is too small should just be ignored. To fix this issue, change the return value of rte_mempool_populate_iova() to 0 when no object can be populated, so it can be ignored by the caller. As this would be an API/ABI change, only do this modification internally for now. Fixes: 354788b60cfd ("mempool: allow populating with unaligned virtual area") Signed-off-by: Olivier Matz Tested-by: Anatoly Burakov Tested-by: Alvin Zhang --- lib/librte_mempool/rte_mempool.c | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c index aea597224a..08906df9ee 100644 --- a/lib/librte_mempool/rte_mempool.c +++ b/lib/librte_mempool/rte_mempool.c @@ -297,8 +297,8 @@ mempool_ops_alloc_once(struct rte_mempool *mp) * zone. Return the number of objects added, or a negative value * on error. */ -int -rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr, +static int +__rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr, rte_iova_t iova, size_t len, rte_mempool_memchunk_free_cb_t *free_cb, void *opaque) { @@ -332,7 +332,7 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr, off = RTE_PTR_ALIGN_CEIL(vaddr, RTE_MEMPOOL_ALIGN) - vaddr; if (off > len) { - ret = -EINVAL; + ret = 0; goto fail; } @@ -343,7 +343,7 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr, /* not enough room to store one object */ if (i == 0) { - ret = -EINVAL; + ret = 0; goto fail; } @@ -356,6 +356,21 @@ fail: return ret; } +int +rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr, + rte_iova_t iova, size_t len, rte_mempool_memchunk_free_cb_t *free_cb, + void *opaque) +{ + int ret; + + ret = __rte_mempool_populate_iova(mp, vaddr, iova, len, free_cb, + opaque); + if (ret == 0) + ret = -EINVAL; + + return ret; +} + static rte_iova_t get_iova(void *addr) { @@ -406,8 +421,10 @@ rte_mempool_populate_virt(struct rte_mempool *mp, char *addr, break; } - ret = rte_mempool_populate_iova(mp, addr + off, iova, + ret = __rte_mempool_populate_iova(mp, addr + off, iova, phys_len, free_cb, opaque); + if (ret == 0) + continue; if (ret < 0) goto fail; /* no need to call the free callback for next chunks */ @@ -415,6 +432,9 @@ rte_mempool_populate_virt(struct rte_mempool *mp, char *addr, cnt += ret; } + if (cnt == 0) + return -EINVAL; + return cnt; fail: -- 2.20.1 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2020-02-11 11:17:42.746396933 +0000 +++ 0114-mempool-fix-populate-with-small-virtual-chunks.patch 2020-02-11 11:17:38.580004713 +0000 @@ -1,8 +1,10 @@ -From 43503c59adee6cae7069da23e105c24e044bf72c Mon Sep 17 00:00:00 2001 +From 68481604c1baa5e23731bc381930e650bc60c7c5 Mon Sep 17 00:00:00 2001 From: Olivier Matz Date: Fri, 17 Jan 2020 15:57:52 +0100 Subject: [PATCH] mempool: fix populate with small virtual chunks +[ upstream commit 43503c59adee6cae7069da23e105c24e044bf72c ] + To populate a mempool with a virtual area, the mempool code calls rte_mempool_populate_iova() for each iova-contiguous area. It happens (rarely) that this area is too small to store one object. In this case, @@ -18,7 +20,6 @@ only do this modification internally for now. Fixes: 354788b60cfd ("mempool: allow populating with unaligned virtual area") -Cc: stable@dpdk.org Signed-off-by: Olivier Matz Tested-by: Anatoly Burakov