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]
Message-ID: <20230905075052.KwIVTze9@linutronix.de>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ