Re: [PATCH] AMD Opteron Rev. E hack

2009/11/5 Kostik Belousov <kostikbel_at_gmail.com>:
> On Thu, Nov 05, 2009 at 01:24:53PM +0100, Giovanni Trematerra wrote:
>> On Thu, Nov 5, 2009 at 12:28 PM, Kostik Belousov <kostikbel_at_gmail.com> wrote:
>>
>> >
>> > Aren't atomic_readandclear need the same workaround ?
>> >
>>
>> I understood that the bug manifests itself only when lock instruction is used.
>> atomic_readandclear doesn't use lock.
> xchgl uses lock implicitely:
>
> If a memory operand is referenced, the processor's locking protocol is
> automatically implemented for the duration of the exchange operation,
> regardless of the presence or absence of the LOCK prefix or of the value
> of the IOPL.
>
>> I think i386/linux/linux_support.s and amd64/linux32/linux32_support.s
>> need the work-around too.
> What about casuword32 ?
> It is actually unclear from the bug description whether we need it there.
> Description states "a locked instruction doesn't act as a read-acquire
> barrier if followed by a non-locked read-modify-write instruction."
>
> casuword32 for amd64, for instance, does movq immediately after
> cmpxchgl, that is a store op, not read-modify-store. So, does it need a
> workaround ? Similar stores are performed in linux32_support.s.
>
> atomic.h functions definitely need your workaround since they are inlined.
>
> Also, I remember that bind(8) provides its own atomic implementation.

However, that fix is not simple to got as one would think.
Our atomics implementation on ia32 and amd64 assume rel/acq barriers
aims for the same code but this problem introduces asymmetric
behaviour between them.

The good way to fix this is to offer an lfence on acq barriers and
leave the other cases untouched, but this could be meaning
re-structure out atomic.h a lot. I will try to think to a good way to
do that when I have more available time.
In the while the WARNING msg will do its job (I can still trimm the
URL path however).

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein