[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