DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] net/af_xdp: fix integer overflow in umem size calculation
@ 2020-10-29 11:25 Martin Weiser
  2020-10-29 12:41 ` Martin Weiser
  0 siblings, 1 reply; 3+ messages in thread
From: Martin Weiser @ 2020-10-29 11:25 UTC (permalink / raw)
  To: Ciara Loftus, Qi Zhang; +Cc: dev, Martin Weiser

The multiplication of two u32 integers may cause an overflow with large
mempool sizes.

Fixes: 74b46340e2d4 ("net/af_xdp: support shared UMEM")
Cc: ciara.loftus@intel.com

Signed-off-by: Martin Weiser <martin.weiser@allegro-packets.com>
---
 drivers/net/af_xdp/rte_eth_af_xdp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c b/drivers/net/af_xdp/rte_eth_af_xdp.c
index df2767b81..4076ff797 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -968,7 +968,8 @@ xsk_umem_info *xdp_umem_configure(struct pmd_internals *internals,
 
 		umem->mb_pool = mb_pool;
 		base_addr = (void *)get_base_addr(mb_pool, &align);
-		umem_size = mb_pool->populated_size * usr_config.frame_size +
+		umem_size = (uint64_t)mb_pool->populated_size *
+				(uint64_t)usr_config.frame_size +
 				align;
 
 		ret = xsk_umem__create(&umem->umem, base_addr, umem_size,
-- 
2.29.1


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] [PATCH] net/af_xdp: fix integer overflow in umem size calculation
  2020-10-29 11:25 [dpdk-dev] [PATCH] net/af_xdp: fix integer overflow in umem size calculation Martin Weiser
@ 2020-10-29 12:41 ` Martin Weiser
  2020-10-30 15:01   ` Ferruh Yigit
  0 siblings, 1 reply; 3+ messages in thread
From: Martin Weiser @ 2020-10-29 12:41 UTC (permalink / raw)
  To: Ciara Loftus, Qi Zhang; +Cc: dev

Hi,

the reason why I stumbled across this issue is because I was getting
inconsistent errors during interface rx queue setup.
We generally use quite large mempools and it looks like the umem setup
fails for larger sizes. But because of the integer overflow the
umem_size sometimes became small enough to let the umem setup work, so
it was not immediately obvious what was going wrong.

It seems that the umem setup (specifically the setsockopt call with
XDP_UMEM_REG in libbpf's xsk_umem__create_v0_0_4()) fails with any
length greater than 2GB and returns ENOMEM. This at least happens on our
systems with kernel 5.8.
Are you aware of any such kernel-side limitation? This basically makes
af_xdp unusable with mempools larger than 2GB.

Best regards,
Martin


Am 29.10.20 um 12:25 schrieb Martin Weiser:
> The multiplication of two u32 integers may cause an overflow with large
> mempool sizes.
>
> Fixes: 74b46340e2d4 ("net/af_xdp: support shared UMEM")
> Cc: ciara.loftus@intel.com
>
> Signed-off-by: Martin Weiser <martin.weiser@allegro-packets.com>
> ---
>  drivers/net/af_xdp/rte_eth_af_xdp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c b/drivers/net/af_xdp/rte_eth_af_xdp.c
> index df2767b81..4076ff797 100644
> --- a/drivers/net/af_xdp/rte_eth_af_xdp.c
> +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
> @@ -968,7 +968,8 @@ xsk_umem_info *xdp_umem_configure(struct pmd_internals *internals,
>  
>  		umem->mb_pool = mb_pool;
>  		base_addr = (void *)get_base_addr(mb_pool, &align);
> -		umem_size = mb_pool->populated_size * usr_config.frame_size +
> +		umem_size = (uint64_t)mb_pool->populated_size *
> +				(uint64_t)usr_config.frame_size +
>  				align;
>  
>  		ret = xsk_umem__create(&umem->umem, base_addr, umem_size,


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] [PATCH] net/af_xdp: fix integer overflow in umem size calculation
  2020-10-29 12:41 ` Martin Weiser
@ 2020-10-30 15:01   ` Ferruh Yigit
  0 siblings, 0 replies; 3+ messages in thread
From: Ferruh Yigit @ 2020-10-30 15:01 UTC (permalink / raw)
  To: Martin Weiser, Ciara Loftus, Qi Zhang; +Cc: dev

On 10/29/2020 12:41 PM, Martin Weiser wrote:
> Hi,
> 
> the reason why I stumbled across this issue is because I was getting
> inconsistent errors during interface rx queue setup.
> We generally use quite large mempools and it looks like the umem setup
> fails for larger sizes. But because of the integer overflow the
> umem_size sometimes became small enough to let the umem setup work, so
> it was not immediately obvious what was going wrong.
> 
> It seems that the umem setup (specifically the setsockopt call with
> XDP_UMEM_REG in libbpf's xsk_umem__create_v0_0_4()) fails with any
> length greater than 2GB and returns ENOMEM. This at least happens on our
> systems with kernel 5.8.
> Are you aware of any such kernel-side limitation? This basically makes
> af_xdp unusable with mempools larger than 2GB.
> 
> Best regards,
> Martin
> 
> 
> Am 29.10.20 um 12:25 schrieb Martin Weiser:
>> The multiplication of two u32 integers may cause an overflow with large
>> mempool sizes.
>>
>> Fixes: 74b46340e2d4 ("net/af_xdp: support shared UMEM")
>> Cc: ciara.loftus@intel.com
>>
>> Signed-off-by: Martin Weiser <martin.weiser@allegro-packets.com>

Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied to dpdk-next-net/main, thanks.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-10-30 15:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-29 11:25 [dpdk-dev] [PATCH] net/af_xdp: fix integer overflow in umem size calculation Martin Weiser
2020-10-29 12:41 ` Martin Weiser
2020-10-30 15:01   ` Ferruh Yigit

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).