confirm 179e695f420474677205db49a8cbfe950329975c
confirm 0da5e6b1343dcc6395ebcc8054c362d930498440
On Fri, Nov 09, 2012 at 09:57:49AM +0800, Shan Hai wrote:
The locking in update_vsyscall_tz() is not only unnecessary because the vdso
code copies the data unproteced in __kernel_gettimeofday() but also
introduces a hard to reproduce race condition between update_vsyscall
code.
The following patch removes the locking from update_vsyscall_tz().
---
arch/powerpc/kernel/time.c |5 -
1 file changed, 5 deletions(-)
Thanks
Shan Hai
From 167eac293b07e0ee201ffe5043ec442d52495a48 Mon Sep 17 00:00:00 2001
From: Shan Hai shan@windriver.com
Date: Mon, 5 Nov 2012
the threads [PATCH 0/1] Fixup write permission of TLB on
powerpc e500 core
and [PATCH 1/1] Fixup write permission of TLB on powerpc e500 core for
the whole story.
Provided the test case code in the [PATH 0/1].
Thanks
Shan Hai
(Documentation/stable_kernel_rules.txt, 4th bullet)
(And it's not just
On 07/19/2011 03:46 PM, Benjamin Herrenschmidt wrote:
On Tue, 2011-07-19 at 13:38 +0800, Shan Hai wrote:
What you said is another path, that is futex_wake_op(),
but what about futex_lock_pi in which my test case failed?
your patch will call handle_mm_fault on every futex contention
was set, and the
reason why the fault was taken is that because of violation of
permission on present and writable user page occurred on sw
dirty/young tracking architectures.
Thanks
Shan Hai
David
___
Linuxppc-dev mailing list
Linuxppc-dev
?
__get_user_pages()
while (!(page = follow_page(vma, start, foll_flags))) {
...
ret = handle_mm_fault(mm, vma, start,
fault_flags);
...
}
Thanks
Shan Hai
___
Linuxppc-dev
On 07/18/2011 03:01 PM, Benjamin Herrenschmidt wrote:
On Mon, 2011-07-18 at 14:48 +0800, Shan Hai wrote:
It could not fix the problem, refer the following reply for
the reasons.
.../...
diff --git a/kernel/futex.c b/kernel/futex.c
index fe28dc2..02adff7 100644
--- a/kernel/futex.c
+++ b
On 07/18/2011 03:36 PM, Benjamin Herrenschmidt wrote:
On Mon, 2011-07-18 at 15:26 +0800, Shan Hai wrote:
I am sorry I hadn't tried your newer patch, I tried it but it still
could not work in my test environment, I will dig into and tell you
why that failed later.
Ok, please let me know what
similar to my first posted patch, the difference is that
I tried to do it in the futex_atomic_cmpxchg_inatomic() in
the ppc specific path, lower level than yours as in
fault_in_user_writable :-)
Anyway, I will notify you on the test result.
Thanks
Shan Hai
Cheers,
Ben.
diff --git a/include
the stupid errors in my original patch if the concept
is acceptable)
in this way we could decrease the overhead of handle_mm_fault
in the path which does not need write permission fixup.
Thanks
Shan Hai
Cheers,
Ben.
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 9670f71..1036614
On 07/19/2011 01:24 PM, Benjamin Herrenschmidt wrote:
On Tue, 2011-07-19 at 13:17 +0800, Shan Hai wrote:
The patch works, but I have certain confusions,
- Do we want to handle_mm_fault on each futex_lock_pi
even though in most cases there is no write permission
fixup's needed
,
so the gup(.write=1) has no chance to set pte dirty by calling
handle_mm_fault,
the follow_page() has no knowledge of supervisor-mode write protected pages,
that's the culprit in the bug discussed here.
Thanks
Shan Hai
___
Linuxppc-dev mailing list
On 07/17/2011 10:48 PM, Benjamin Herrenschmidt wrote:
On Sun, 2011-07-17 at 21:33 +0800, Shan Hai wrote:
On ARM you could not protect pages from supervisor-mode writes,
isn't it? That means, all writable user pages are writable for
supervisor too, but its not hold for at least x86 and powerpc
On 07/15/2011 06:23 AM, Peter Zijlstra wrote:
On Fri, 2011-07-15 at 16:07 +0800, Shan Hai wrote:
The kernel has no write permission on COW pages by default on e500 core, this
will cause endless loop in futex_lock_pi, because futex code assumes the kernel
has write permission on COW pages. Grant
On 07/15/2011 08:20 PM, Benjamin Herrenschmidt wrote:
On Fri, 2011-07-15 at 11:32 -0400, Shan Hai wrote:
I agree with you, the problem could be triggered by accessing
any user space page which has kernel read only permission
in the page fault disabled context, the problem also affects
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
The following test case could reveal a bug in the futex_lock_pi()
BUG: On FUTEX_LOCK_PI, there is a infinite loop in the futex_lock_pi()
on Powerpc e500 core.
Cause: The linux kernel on the e500 core has no write permission on
the COW page, refer the head comment of the following
-by: Shan Hai haishan@gmail.com
---
arch/powerpc/include/asm/futex.h | 11 ++-
arch/powerpc/include/asm/tlb.h | 25 +
2 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/futex.h b/arch/powerpc/include/asm/futex.h
index
On 07/15/2011 04:44 PM, Peter Zijlstra wrote:
On Fri, 2011-07-15 at 16:38 +0800, MailingLists wrote:
On 07/15/2011 04:20 PM, Peter Zijlstra wrote:
On Fri, 2011-07-15 at 16:07 +0800, Shan Hai wrote:
The following test case could reveal a bug in the futex_lock_pi()
BUG: On FUTEX_LOCK_PI
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
On 07/15/2011 06:23 AM, Peter Zijlstra wrote:
On Fri, 2011-07-15 at 16:07 +0800, Shan Hai wrote:
The kernel has no write permission on COW pages by default on e500 core, this
will cause endless loop in futex_lock_pi, because futex code assumes the kernel
has write permission on COW pages. Grant
, the commit 6cfd8990e27d3a491c1c605d6cbc18a46ae51fef
removed the write permission fixup from TLB miss handlers and left it to
generic code, so it might be right time to fixup the write permission here
in the generic code.
Thanks
Shan Hai
David
The following test case failed on Powerpc sbc8548 with CONFIG_SPE
static float fm;
static signed int si_min = (-2147483647 - 1);
static unsigned int ui;
int main()
{
fm = (float) si_min; ;
ui = (unsigned int)fm;
printf(ui=%d, should be %d\n, ui, si_min);
return
Conversion from float to integer should based on both the instruction
encoding and the sign of the operand.
Signed-off-by: Shan Hai shan@windriver.com
---
arch/powerpc/math-emu/math_efp.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/math
26 matches
Mail list logo
