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

From: Shan Hai
Date: Sat Jul 16 2011 - 11:36:39 EST

On 07/15/2011 11:24 AM, Peter Zijlstra wrote:
On Fri, 2011-07-15 at 11:18 -0400, Shan Hai wrote:

+ vma = find_vma(mm, address);
Uhm, find_vma() needs mmap_sem, and futex_atomic_cmpxchg_inatomic() is
most certainly not called with that lock held.

My fault, that will be fixed in the V2 patch.
But you cannot, the function isn't called _atomic_ just for kicks, its
used while holding spinlocks.

Yes we can do that, _atomic_ here is just atomic for cmpxchg
implemented by the combination of 'lwarx' and 'stwcx.' instructions
as done in the spin lock implementation, so even we hold the
mmap_sem that has no impact on the _atomic_ feature of the

+ if (likely(vma)) {
+ /* only fixup present page */
+ if (follow_page(vma, address, FOLL_WRITE)) {
+ handle_mm_fault(mm, vma, address, FAULT_FLAG_WRITE);
So how can this toggle your sw dirty/young tracking, that's pretty much
what gup(.write=1) does too!

because of the kernel read only permission of the page is transparent
to the follow_page(), the handle_mm_fault() is not to be activated
in the __get_use_pages(), so the gup(.write=1) could not help to fixup
the write permission.
So why do you need the vma? Is it like I wrote earlier that you don't
have spare PTE bits and need the vma flags to see if it may become

Need vma for the reason to call handle_mm_fault(), that's all.

gup(.write=1) not triggering this is a serious problem though, not
something you can just paper over. I wouldn't be at all surprised to
find there's more things broken because of that.

In my opinion another solution might be check the read only for kernel
feature of a page in the follow_page() on gup(.write=1) to avoid this
problem on all architectures.

Shan Hai

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at