netdev - Re: [PATCH net-next v2 2/3] bnxt: use READ_ONCE/WRITE

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: <78cea5774de414fa3bcbd6ef02e436ae6b5706c1.camel@redhat.com>
Date:   Thu, 13 Apr 2023 13:38:08 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     David Laight <David.Laight@...LAB.COM>,
        'Jakub Kicinski' <kuba@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>
Subject: Re: [PATCH net-next v2 2/3] bnxt: use READ_ONCE/WRITE_ONCE for ring
 indexes

On Wed, 2023-04-12 at 08:15 +0000, David Laight wrote:
> From: Jakub Kicinski
> > Sent: 12 April 2023 02:51
> > 
> > Eric points out that we should make sure that ring index updates
> > are wrapped in the appropriate READ_ONCE/WRITE_ONCE macros.
> > 
> ...
> > -static inline u32 bnxt_tx_avail(struct bnxt *bp, struct bnxt_tx_ring_info *txr)
> > +static inline u32 bnxt_tx_avail(struct bnxt *bp,
> > +				const struct bnxt_tx_ring_info *txr)
> >  {
> > -	/* Tell compiler to fetch tx indices from memory. */
> > -	barrier();
> > +	u32 used = READ_ONCE(txr->tx_prod) - READ_ONCE(txr->tx_cons);
> > 
> > -	return bp->tx_ring_size -
> > -		((txr->tx_prod - txr->tx_cons) & bp->tx_ring_mask);
> > +	return bp->tx_ring_size - (used & bp->tx_ring_mask);
> >  }
> 
> Doesn't that function only make sense if only one of
> the ring index can be changing?
> In this case I think this is being used in the transmit path
> so that 'tx_prod' is constant and is either already read
> or need not be read again.
> 
> Having written a lot of 'ring access' functions over the years
> if the ring size is a power of 2 I'd mask the 'tx_prod' value
> when it is being used rather than on the increment.
> (So the value just wraps modulo 2**32.)
> This tends to make the code safer - especially since the
> 'ring full' and 'ring empty' conditions are different.
> 
> Also that code is masking with bp->tx_ring_mask, but the
> increments (in hunks I've chopped) use NEXT_TX(prod).
> If that is masking with bp->tx_ring_mask then 'bp' should
> be a parameter.

AFAICS bnxt_tx_avail() is also used in TX interrupt, outside tx path/tx
lock.

I think all the above consideration are more suited for a driver
refactor, while the current patch specifically address potential data
race issues.

Cheers,

Paolo