Re: [PATCH 0/1] Fixup write permission of TLB on powerpc e500 core

[Shan Hai]

On 07/15/2011 05:50 PM, Peter Zijlstra wrote:
> 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
> > - 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()
> but that's a bug right there, gup(.write=1) _should_ be a complete write
> fault, and as such toggle your sw dirty/young tracking.

The fault causing futex_atomic_cmpxchg_inatomic() is
protected by pagefault_disable(), so the page fault handler has
no chance to toggle the SW dirty/young tracking.

Thanks
Shan Hai

> > - futex_lock_pi_atomic() -->  futex_atomic_cmpxchg_inatomic(),
> >       another write protection page fault
> > - infinite loop

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/