netdev - Re: [RFC PATCH] bnx2x: fix tx queue locking and memory barriers

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: <318.1268245970@redhat.com>
Date:	Wed, 10 Mar 2010 18:32:50 +0000
From:	David Howells <dhowells@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	dhowells@...hat.com, sgruszka@...hat.com, vladz@...adcom.com,
	paulmck@...ux.vnet.ibm.com, netdev@...r.kernel.org,
	eilong@...adcom.com
Subject: Re: [RFC PATCH] bnx2x: fix tx queue locking and memory barriers

David Miller <davem@...emloft.net> wrote:

> > The barrier() didn't tell the compiler that fp->tx_bd_prod and
> > fp->tx_bd_cons could change.  What it did was to say that the accesses to
> > those two variables must be performed after all the other accesses issued
> > by that CPU prior to the barrier - at least as far as the compiler is
> > concerned.
> 
> barrier() has a "memory" asm clobber which says that all memory could
> have changed.

Indeed, but only as far as the compiler is concerned.

However, the problem is almost certainly not this, but that the item to be
read from the buffer may not have been written yet by the producing CPU, even
though it's written the head pointer.

David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html