Oliver Neukum <[EMAIL PROTECTED]> wrote: > >> synchronize by a lock then it will always see the correct value, since the >> unlocking functions -- up() and spin_unlock() -- include write barriers. > > The issue is not the pointer itself. The problem is the memory the pointer > is pointing to. Iff the new pointer is returned the caller can expect that > that area of memory is initialised. Therefore the barrier must be before > the assignment. If you depend on the lock's barrier there's a window > in which the assumption is not necessarily true.
Can you please give a sample execution path that triggers this bug? -- 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 ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
