netdev - Re: [PATCH net] octeontx2-pf: Fix page pool cache index corruption.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 5 Sep 2023 09:50:52 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Ratheesh Kannoth <rkannoth@...vell.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	sgoutham@...vell.com, gakula@...vell.com, sbhatta@...vell.com,
	hkelam@...vell.com, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, hawk@...nel.org,
	alexander.duyck@...il.com, ilias.apalodimas@...aro.org,
	linyunsheng@...wei.com
Subject: Re: [PATCH net] octeontx2-pf: Fix page pool cache index corruption.

On 2023-09-04 20:13:04 [+0530], Ratheesh Kannoth wrote:
…
> 
> Fixes: b2e3406a38f0 ("octeontx2-pf: Add support for page pool")
Reported-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> Signed-off-by: Ratheesh Kannoth <rkannoth@...vell.com>

> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
> index e369baf11530..cf2e631af58b 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_txrx.c
> @@ -561,10 +566,18 @@ int otx2_napi_handler(struct napi_struct *napi, int budget)
>  				otx2_config_irq_coalescing(pfvf, i);
>  		}
>  
> -		/* Re-enable interrupts */
> -		otx2_write64(pfvf, NIX_LF_CINTX_ENA_W1S(cq_poll->cint_idx),
> -			     BIT_ULL(0));
> +		/* Schedule NAPI again to refill rx buffers */
> +		if (unlikely(!filled_cnt)) {
> +			udelay(1000);

A delay of 1ms? Short term I would suggest to set up a timer for polling
this case instead of delay. On a UP you wouldn't make progress that way.

Long term it might make sense to allocate new page/ memory before
handing the current page/skb over to the stack. Should allocation fail
then you have at least one slot (your current one) which can ensure that
you can receive on further packet (which you either drop on the floor or
pass to the stack).

> +			napi_schedule(napi);
> +		} else {
> +			/* Re-enable interrupts */
> +			otx2_write64(pfvf,
> +				     NIX_LF_CINTX_ENA_W1S(cq_poll->cint_idx),
> +				     BIT_ULL(0));
> +		}
>  	}
> +
>  	return workdone;
>  }

Sebastian