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
| ||
|
Message-ID: <540DB314.3090809@oracle.com> Date: Mon, 08 Sep 2014 09:45:56 -0400 From: David L Stevens <david.stevens@...cle.com> To: Sowmini Varadhan <sowmini.varadhan@...cle.com>, David Miller <davem@...emloft.net> CC: netdev@...r.kernel.org Subject: Re: [PATCH net-next v2 2/2] Re-check for a VIO_DESC_READY data descriptor after short udelay() Sowmini, On 09/06/2014 05:02 PM, Sowmini Varadhan wrote: > Stared at this a bit over the last two days, checked > the documentation, discussed with dls offline - looks like > (a) the rmb() thing was mostly a red-herring/fud > (b) we do need the wmb() I don't think this has anything to do with your patch, but my (new) concern with the wmb() and no matching rmb() is this text from Documentation/memory-barrier.txt: > SMP BARRIER PAIRING > ------------------- > > When dealing with CPU-CPU interactions, certain types of memory barrier should > always be paired. A lack of appropriate pairing is almost certainly an error. I'm no mb expert, and I know of no symptoms, but it appears to be saying that load reordering could result in a race where the READY flag could be set with old data in other descriptor fields due to loading them in a different order -- something it says wmb() on another CPU explicitly does not prevent. The particular case would be adding to the ring at the same time the other side is removing from the ring, so no locks or LDC traffic would affect it. So, it appears to me we have a missing rmb() that is needed and I don't know what leads you to believe it isn't. +-DLS -- 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
Powered by blists - more mailing lists