net/af_xdp: fix integer overflow in umem size calculation

  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(-)
  

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,
  

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.