[dpdk-stable] patch 'mempool: fix allocation in memzone during retry' has been queued to stable release 19.11.4
luca.boccassi at gmail.com
luca.boccassi at gmail.com
Fri Jul 24 14:00:18 CEST 2020
Hi,
FYI, your patch has been queued to stable release 19.11.4
Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 07/26/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 fe11e4ef38d6a932881ad0424853736159eeb890 Mon Sep 17 00:00:00 2001
From: Zhike Wang <wangzhike at jd.com>
Date: Tue, 14 Jul 2020 15:26:05 +0800
Subject: [PATCH] mempool: fix allocation in memzone during retry
[ upstream commit 9dbe628a7ba2420d00bf8c15d066f9667092db2b ]
If allocation is successful on the first attempt, typically
there is no problem since we allocated everything required and
we'll terminate the loop (if memory chunk is really sufficient
to populate required number of mempool elements).
If the first attempt fails, we try to allocate half
of mem_size and it succeed, we'll have one more iteration of
the for-loop to allocate memory for remaining elements and
should not try the next time with quarter of the mem_size.
It is wrong that max_alloc_size is divided by 2 in the
case of successful allocation as well, or invalid memory
can be allocated, and leads to population failure, then errno
other than ENOMEM may be returned.
Fixes: 3a3d0c75b43e ("mempool: fix slow allocation of large pools")
Signed-off-by: Andrew Rybchenko <arybchenko at solarflare.com>
Signed-off-by: Zhike Wang <wangzhike at jd.com>
Acked-by: Anatoly Burakov <anatoly.burakov at intel.com>
---
lib/librte_mempool/rte_mempool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 08906df9e..e39135d47 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -569,7 +569,7 @@ rte_mempool_populate_default(struct rte_mempool *mp)
RTE_MIN((size_t)mem_size, max_alloc_size),
mp->socket_id, mz_flags, align);
- if (mz == NULL && rte_errno != ENOMEM)
+ if (mz != NULL || rte_errno != ENOMEM)
break;
max_alloc_size = RTE_MIN(max_alloc_size,
--
2.20.1
---
Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- - 2020-07-24 12:53:55.494319622 +0100
+++ 0180-mempool-fix-allocation-in-memzone-during-retry.patch 2020-07-24 12:53:48.603012347 +0100
@@ -1,8 +1,10 @@
-From 9dbe628a7ba2420d00bf8c15d066f9667092db2b Mon Sep 17 00:00:00 2001
+From fe11e4ef38d6a932881ad0424853736159eeb890 Mon Sep 17 00:00:00 2001
From: Zhike Wang <wangzhike at jd.com>
Date: Tue, 14 Jul 2020 15:26:05 +0800
Subject: [PATCH] mempool: fix allocation in memzone during retry
+[ upstream commit 9dbe628a7ba2420d00bf8c15d066f9667092db2b ]
+
If allocation is successful on the first attempt, typically
there is no problem since we allocated everything required and
we'll terminate the loop (if memory chunk is really sufficient
@@ -19,7 +21,6 @@
other than ENOMEM may be returned.
Fixes: 3a3d0c75b43e ("mempool: fix slow allocation of large pools")
-Cc: stable at dpdk.org
Signed-off-by: Andrew Rybchenko <arybchenko at solarflare.com>
Signed-off-by: Zhike Wang <wangzhike at jd.com>
@@ -29,10 +30,10 @@
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
-index a2bd24984..7774f0c8d 100644
+index 08906df9e..e39135d47 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
-@@ -635,7 +635,7 @@ rte_mempool_populate_default(struct rte_mempool *mp)
+@@ -569,7 +569,7 @@ rte_mempool_populate_default(struct rte_mempool *mp)
RTE_MIN((size_t)mem_size, max_alloc_size),
mp->socket_id, mz_flags, align);
More information about the stable
mailing list