[lkml]   [2015]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
On Mon, Oct 26, 2015 at 11:20:01AM +0900, Michael Ellerman wrote:
> Sorry guys, these threads are so long I tend not to read them very actively :}
> Looking at the system call path, the straight line path does not include any
> barriers. I can't see any hidden in macros either.
> We also have an explicit sync in the switch_to() path, which suggests that we
> know system call is not a full barrier.
> Also looking at the architecture, section 1.5 which talks about the
> synchronisation that occurs on system calls, defines nothing in terms of
> memory ordering, and includes a programming note which says "Unlike the
> Synchronize instruction, a context synchronizing operation does not affect the
> order in which storage accesses are performed.".

Thank you, Michael. So IIUC, "sc" and "rfid" just imply an execution
barrier like "isync" rather than a memory barrier. So memory barriers
are needed if a system call need a memory ordering guarantee.


> Whether that's actually how it's implemented I don't know, I'll see if I can
> find out.
> cheers
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2015-10-26 10:21    [W:0.139 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site