[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM6PR18MB2697C972B49EAD3AE7C3F37AABC80@DM6PR18MB2697.namprd18.prod.outlook.com>
Date: Thu, 18 Jul 2019 10:12:20 +0000
From: Manish Chopra <manishc@...vell.com>
To: Brian King <brking@...ux.vnet.ibm.com>,
GR-everest-linux-l2 <GR-everest-linux-l2@...vell.com>
CC: Sudarsana Reddy Kalluru <skalluru@...vell.com>,
Ariel Elior <aelior@...vell.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [EXT] [PATCH] bnx2x: Prevent load reordering in tx completion
processing
> -----Original Message-----
> From: Brian King <brking@...ux.vnet.ibm.com>
> Sent: Tuesday, July 16, 2019 3:12 AM
> To: GR-everest-linux-l2 <GR-everest-linux-l2@...vell.com>
> Cc: Sudarsana Reddy Kalluru <skalluru@...vell.com>; Ariel Elior
> <aelior@...vell.com>; netdev@...r.kernel.org; Brian King
> <brking@...ux.vnet.ibm.com>
> Subject: [EXT] [PATCH] bnx2x: Prevent load reordering in tx completion
> processing
>
> External Email
>
> ----------------------------------------------------------------------
> This patch fixes an issue seen on Power systems with bnx2x which results in
> the skb is NULL WARN_ON in bnx2x_free_tx_pkt firing due to the skb pointer
> getting loaded in bnx2x_free_tx_pkt prior to the hw_cons load in
> bnx2x_tx_int. Adding a read memory barrier resolves the issue.
>
> Signed-off-by: Brian King <brking@...ux.vnet.ibm.com>
> ---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> index 656ed80..e2be5a6 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> @@ -285,6 +285,9 @@ int bnx2x_tx_int(struct bnx2x *bp, struct
> bnx2x_fp_txdata *txdata)
> hw_cons = le16_to_cpu(*txdata->tx_cons_sb);
> sw_cons = txdata->tx_pkt_cons;
>
> + /* Ensure subsequent loads occur after hw_cons */
> + smp_rmb();
> +
> while (sw_cons != hw_cons) {
> u16 pkt_cons;
>
> --
> 1.8.3.1
Could you please explain a bit in detail what could have caused skb to NULL exactly ?
Curious that if skb would have been NULL for some reason it did not cause NULL pointer dereference in bnx2x_free_tx_pkt() on below call -
prefetch(&skb->end);
Which is prior to the said WARN_ON(!skb) in bnx2x_free_tx_pkt().
Powered by blists - more mailing lists