-Original Message-
From: Andrew Morton [mailto:a...@linux-foundation.org]
Sent: Friday, July 15, 2011 5:51 AM
To: Xie Shaohui-B21989
Cc: linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Wood Scott-B07421;
pty...@xes-inc.com; dji...@mvista.com; dougthomp...@xmission.com; Jiang
Kai-B18973
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
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 write permission to the kernel on COW
pages when access violation page fault occurs.
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 on
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
On Fri, 2011-07-15 at 10:45 +1000, Anton Blanchard wrote:
Hi,
Urgh.. so those spans are generated by sched_domain_node_span(), and
it looks like that simply picks the 15 nearest nodes to the one we've
got without consideration for overlap with previously generated spans.
I do wonder if
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_lock_pi()
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 TLB
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 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.
And
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
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
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
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 write permission to the kernel on COW
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 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 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
From: Ayman El-Khashab ay...@elkhashab.com
Adds a register to the config space for the 460sx. Changes the vc0
detect to a pll detect. maps configuration space to test the link
status. changes the setup to enable gen2 devices to operate at gen2
speeds. fixes mapping that was not correct for
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
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, it
On Fri, 15 Jul 2011 13:28:15 +0800
tiejun.chen tiejun.c...@windriver.com wrote:
Kumar Gala wrote:
I'm still very confused why we need a unique stack frame for kprobe/program
exceptions on book-e devices.
Its a bug at least for Book-E.
But why only booke? There's nothing booke-specific
On Sat, Jul 09, 2011 at 12:14:09PM +0200, Anatolij Gustschin wrote:
On Wed, 6 Jul 2011 11:52:45 -0600
Grant Likely grant.lik...@secretlab.ca wrote:
On Mon, May 23, 2011 at 11:25:30AM +0200, Anatolij Gustschin wrote:
The mpc52xx_gpio driver currently supports 8 wakeup GPIOs and 32
Hi,
Anyone know what it means when a dual core dual cpu (total 4 cores)
beeps three times on startup? The white power led also blinks 3 times
every few seconds.
The machine in question is a recent acquisition. I have got it to boot once.
Thanks!
kevin
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, it
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 Tue, Jun 28, 2011 at 08:47:09AM -0400, Josh Boyer wrote:
Commit 376ab6f2 removed the old style check functionality from DTC,
however the check option and variable were not removed. This leads to
build failures when -Werror=unused-but-set-variable is specified:
dtc.c: In function
On Tue, Jun 28, 2011 at 09:47:11AM -0400, Josh Boyer wrote:
The *p variable is declared and used to save inb-ptr, however p is
later never used. This has been the case since commit 6c0f3676 and can
lead to build failures with -Werror=unused-but-set-variable:
flattree.c: In function
-Original Message-
From: Scott Wood [mailto:scottw...@freescale.com]
Sent: Saturday, July 16, 2011 2:43 AM
To: Chen, Tiejun
Cc: Kumar Gala; linuxppc-...@ozlabs.org
Subject: Re: [v3 PATCH 1/1] booke/kprobe: make program
exception to use one dedicated exception stack
On Fri, 15
28 matches
Mail list logo
