On Fri, 2011-07-15 at 17:08 +0800, Shan Hai wrote: > The whole scenario should be, > - the child process triggers a page fault at the first time access to > the lock, and it got its own writable page, but its *clean* for > the reason just for checking the status of the lock. > I am sorry for above "unbreakable COW". > - the futex_lock_pi() is invoked because of the lock contention, > and the futex_atomic_cmpxchg_inatomic() tries to get the lock, > it found out the lock is free so tries to write to the lock for > reservation, a page fault occurs, because the page is read only > for kernel(e500 specific), and returns -EFAULT to the caller
There is nothing e500 specific about user read only pages being read only for kernel. All architectures behave the same way here afaik. _However_ there is something not totally x86-like in the fact that we require handle_mm_fault() to deal with dirty and young tracking, which means that we -will- fault for a non-dirty writeable page or for any non-young page. It's quite possible that the page fault disabling occurs before that and thus breaks those architectures (it's not only e500 and afaik not only powerpc) while x86 works fine due to HW update of dirty and young. It might be something to look into. Cheers, Ben. > - the fault_in_user_writeable() tries to fix the fault, > but from the get_user_pages() view everything is ok, because > the COW was already broken, retry futex_lock_pi_atomic() > - futex_lock_pi_atomic() --> futex_atomic_cmpxchg_inatomic(), > another write protection page fault > - infinite loop > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
