net/af_xdp: fix integer overflow in umem size calculation
diff mbox series

Message ID 20201029112542.96131-1-martin.weiser@allegro-packets.com
State Accepted, archived
Delegated to: Ferruh Yigit
Headers show
Series
  • net/af_xdp: fix integer overflow in umem size calculation
Related show

Checks

Context Check Description
ci/iol-mellanox-Performance success Performance Testing PASS
ci/travis-robot success Travis build: passed
ci/iol-intel-Performance success Performance Testing PASS
ci/Intel-compilation success Compilation OK
ci/iol-testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/checkpatch success coding style OK

Commit Message

Martin Weiser Oct. 29, 2020, 11:25 a.m. UTC
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(-)

Comments

Martin Weiser Oct. 29, 2020, 12:41 p.m. UTC | #1
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,
Ferruh Yigit Oct. 30, 2020, 3:01 p.m. UTC | #2
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.

Patch
diff mbox series

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,