[PATCH] Avoid unpaired stwcx. on some processors

Olof Johansson olof at lixom.net
Sat Nov 10 11:18:00 EST 2007


On Fri, Nov 09, 2007 at 05:52:30PM -0600, Becky Bruce wrote:

> I don't think so. It's not plain old dangling stwcx that's the  
> problem.  It's dangling stwcx when the reservation is held to another  
> address. 

Gack, I misread the description. My bad.

> The lwarx that I've added prevents the normally dangling  
> stwcx. in the context switch/syscall  path from meeting this  
> condition.  Any process that gets swapped in and executes stwcx.  
> first thing is fine, because the reservation was previously cleared  
> by the stwcx. in the context switch path.
>
> BTW, I think you're missing a key point here, which is this:  
> Architecturally, there is a single reservation per core.  On e600 and  
> other parts, the stwcx. does *not* take the address into account for  
> success.  If you stwcx, and the reservation is held, it succeeds  
> regardless of the address.   Fun, no?   That's one of the reasons  
> it's so important that the kernel have the dummy stwcx. in place.
>
> Does that make sense?

Yep, it does, doesn't seem to be a better way to work around it.


-Olof



More information about the Linuxppc-dev mailing list