Chris Snook <[EMAIL PROTECTED]> wrote: > > Because atomic operations are generally used for synchronization, which > requires > volatile behavior. Most such codepaths currently use an inefficient > barrier(). > Some forget to and we get bugs, because people assume that atomic_read() > actually reads something, and atomic_write() actually writes something. > Worse, > these are architecture-specific, even compiler version-specific bugs that are > often difficult to track down.
I'm yet to see a single example from the current tree where this patch series is the correct solution. So far the only example has been a buggy piece of code which has since been fixed with a cpu_relax. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
