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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:57 UTC