On Mon, Mar 29, 2010 at 4:07 PM, Kyle McMartin <kyle@xxxxxxxxxxx> wrote: > Can you bounce me the whole thread, please? You saw the whole thread :-) Niibe-san has pointed out that if you call LWS CAS on an address of a shared page, that the COW process may call schedule and sleep, leaving a small window for a race condition. On SMP I don't think there is a problem: * Thread A takes kernel LWS CAS lock. * Thread A writes to CAS address causing COW * Thread A sleeps. * Thread B tries to take kernel LWS CAS lock, fails, returns EAGAIN to userspace. * Thread A eventually completes releasing kernel LWS CAS lock. * Thread B finally takes kernel LWS CAS lock and carries out CAS operation. Even though Thread A sleeps, there is no way to send it a signal at this point. All signal delivery is initiated only via PA assembly in entry.S/syscall.S and that avoids delivering a signal (do_signal, and do_notify_resume not called) if execution is on the gateway page. On UP you have a problem: * Thread A enters LWS CAS (no lock on UP) * Thread A writes to CAS address causing COW * Thread A sleeps. * Thread A completes COW, but finishes time slice before the write is restarted. * Thread B enters LWS CAS (no lock on UP) * Thread B writes to CAS address, and finishes time slice. * Thread A writes to CAS address and clobbers B's value. The solution is to add the locks to the UP case to avoid this problem. 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
