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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
