]> err.no Git - linux-2.6/commit
[IA64] ar.itc access must really be after xtime_lock.sequence has been read
authorHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Fri, 13 Jul 2007 23:21:44 +0000 (16:21 -0700)
committerTony Luck <tony.luck@intel.com>
Fri, 13 Jul 2007 23:21:44 +0000 (16:21 -0700)
commit829a9996259e4d0b20ce7b94c49b985d6ba6b760
tree0ed75d44d279dc233b217a407c7b7f571846235e
parent83e12a076e3587d60cfbe65a761ef54e14a264e3
[IA64] ar.itc access must really be after xtime_lock.sequence has been read

The ".acq" semantics of the load only apply w.r.t. other data access.
Reading the clock (ar.itc) isn't a data access so strange things can
happen here.  Specifically the read of ar.itc can be launched as soon
as the read of xtime_lock.sequence is ISSUED.  Since this may cache
miss, and that might cause a thread switch, and there may be cache
contention for the line containing xtime_lock, it may be a long time
before the actual value is returned, so the ar.itc value may be very
stale.

Move the consumption of r28 up before the read of ar.itc to make sure
that we really have got the current value of xtime_lock.sequence
before look at ar.itc.

Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
arch/ia64/kernel/fsys.S