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] [day] [month] [year] [list]

Date:   Thu, 13 Apr 2023 14:20:51 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Paolo Abeni' <pabeni@...hat.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

From: Paolo Abeni
> Sent: 13 April 2023 12:38
> 
> 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.
> >
...
> 
> AFAICS bnxt_tx_avail() is also used in TX interrupt, outside tx path/tx
> lock.

In which case both tx_prod and tx_cons are subject to possible updates.
It is even possible that the two values have absolutely no relation
to each other, it requires some unusual circumstances, but isn't impossible.
- A high priority interrupt (eg x86 SMM mode) could separate the READ_ONCE().
- Transmit setup will increase tx_prod.
- End of transmit 'reap' often done by other code paths (like rx processing
  or tx setup) can change tx_cons.
So not only is the value immediately stale, it can be just plain wrong.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)