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
architectu
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
> architectures which depend on SW dirty/young tracking as
On Fri, 2011-07-15 at 11:32 +0100, David Laight wrote:
> > 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.
>
> Perhaps that is the bug!
> Whatever pagefault_disable() does,
On Fri, 2011-07-15 at 11:32 +0100, David Laight wrote:
> > 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.
>
> Perhaps that is the bug!
> Whatever pagefault_disable() does,
On 07/15/2011 06:32 AM, David Laight wrote:
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.
Perhaps that is the bug!
Whatever pagefault_disable() does, it shouldn't disable the
> 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.
Perhaps that is the bug!
Whatever pagefault_disable() does, it shouldn't disable the
SW dirty/young tracking - which should
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 che
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 s
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 s
On Fri, 2011-07-15 at 16:38 +0800, MailingLists wrote:
> A page could be set to read only by the kernel (supervisor in the
> powerpc
> literature) on the e500, and that's what the kernel do. Set
> SW(supervisor
> write) bit in the TLB entry to grant write permission to the kernel on
> a
> page.
>
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, there
On Fri, 2011-07-15 at 10:20 +0200, Peter Zijlstra wrote:
> But but but but, that get_user_pages(.write=1, .force=0) should result
> in a COW break, getting our own writable page.
>
> What is this e500 thing smoking that this doesn't work?
Right. That should have triggered the cow & flushed the T
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, there is a infinite loop in the futex
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, there is a infinite loop in the futex_lock_pi()
on Powerpc e500 core.
Cause: The linux kernel on the
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, 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 o
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
16 matches
Mail list logo
