On Sat, 19 Jun 2004, Oliver Neukum wrote:
> Hi,
>
> there's an SMP memory ordering issue with usb_get/set_intfdata.
> If a CPU reorders writes, another CPU may use usb_get_intfdata
> to get a pointer which is uninitialised because the initialising CPU
> has not yet written the data.
> This problem is not confined to USB, so I tackled it at the root.
> Comments?
> static inline void
> class_set_devdata (struct class_device *dev, void *data)
> {
> + smp_wmb();
> dev->class_data = data;
> }
>
> @@ -310,6 +311,7 @@
> static inline void
> dev_set_drvdata (struct device *dev, void *data)
> {
> + smp_wmb();
> dev->driver_data = data;
> }
Shouldn't these barrier instructions be placed _after_ the assignments?
Regardless, I think this is a non-problem. If a driver calls
usb_get_intfdata() during probe() or disconnect() then the usb_device is
locked. Another processor that doesn't synchronize by locking shouldn't
have any expectations about which value it will see. If it does
synchronize by a lock then it will always see the correct value, since the
unlocking functions -- up() and spin_unlock() -- include write barriers.
Alan Stern
-------------------------------------------------------
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
