Alan Stern wrote:
Regardless, I think this is a non-problem.
I agree. The relevant synchronization is a bit higher up the stack.
- Dave
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training,
On Sun, 20 Jun 2004, Oliver Neukum wrote:
> > I don't see the problem. If the other processor synchronizes properly
> > then the write barrier in the unlock function will guarantee that both the
> > pointer and the memory it points to are initialized. Unless the first
> > processor doesn't in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Sonntag, 20. Juni 2004 16:20 schrieb Alan Stern:
> On Sun, 20 Jun 2004, Oliver Neukum wrote:
>
> > > synchronize by a lock then it will always see the correct value, since the
> > > unlocking functions -- up() and spin_unlock() -- include write ba
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Sonntag, 20. Juni 2004 13:18 schrieb Herbert Xu:
> 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 bar
On Sun, 20 Jun 2004, Oliver Neukum 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. I
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. If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Sonntag, 20. Juni 2004 01:20 schrieb Alan Stern:
> 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
> > t
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 proble
