On Mon, Mar 29, 2010 at 9:54 PM, John David Anglin <dave@xxxxxxxxxxxxxxxxxx> wrote: > I think the solution may be to proceed the CAS sequence with a probe,w > instruction. This will trigger a non-access TLB miss fault/non-access > data page fault if its going to happen. There is a FIXME for case 17 > in handle_interruption about this. Then what though? One process has to write to the page to initiate the COW. How else are you going to initiate the COW? Once in userspace you are only allowed to write to the CAS value (one word on a page), and you *can't* because that would violate the CAS semantics and atomicity requirements. The "first" process must take the lock, has to write the result to the page, has to initiate the COW, has to sleep with the lock held, and the rest have to spin in userpace waiting for it to complete. AFAICT the rest of the processes are not be able to stop the "first" process from finishing the COW, so we make forward progress after the COW is done and the "first" process resumes and unlocks the LWS CAS lock (for that address range). Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html