On 01/10/2014 03:06 PM, Peter Zijlstra wrote:
:-)
Something like this perhaps?
---
Subject: x86, mm: Allow double faults from interrupts
Waiman managed to trigger a PMI while in a emulate_vsyscall() fault, the
PMI in turn managed to trigger a fault while obtaining a stack trace.
This
On 01/10/2014 03:06 PM, Peter Zijlstra wrote:
:-)
Something like this perhaps?
---
Subject: x86, mm: Allow double faults from interrupts
Waiman managed to trigger a PMI while in a emulate_vsyscall() fault, the
PMI in turn managed to trigger a fault while obtaining a stack trace.
This
On Fri, Jan 10, 2014 at 12:06 PM, Peter Zijlstra wrote:
> On Fri, Jan 10, 2014 at 10:54:52AM -0800, Andy Lutomirski wrote:
>> Yuck -- when I wrote that thing, I hadn't imagined that an interrupt
>> (there's nothing particularly special about NMIs here, I think) would
>> try to access user memory.
On Fri, Jan 10, 2014 at 11:56:07AM -0800, Andy Lutomirski wrote:
> - The perf callchain code tries to read from a bad userspace pointer
> (not sure why -- the ip value in the vsyscall page *is* readable).
> That traps (as expected), but the trap handler injects SIGSEGV due to
>
On Fri, Jan 10, 2014 at 02:37:10PM -0500, Waiman Long wrote:
> >@@ -641,7 +641,7 @@ no_context(struct pt_regs *regs, unsigned long
> >error_code,
> >
> > /* Are we prepared to handle this kernel fault? */
> > if (fixup_exception(regs)) {
> >-if
On Fri, Jan 10, 2014 at 10:54:52AM -0800, Andy Lutomirski wrote:
> Yuck -- when I wrote that thing, I hadn't imagined that an interrupt
> (there's nothing particularly special about NMIs here, I think) would
> try to access user memory. The fix below looks okay, but IMO it needs
> a big fat
On Fri, Jan 10, 2014 at 11:43 AM, Waiman Long wrote:
> On 01/10/2014 01:54 PM, Andy Lutomirski wrote:
>>
>> On Fri, Jan 10, 2014 at 9:41 AM, Peter Zijlstra
>> wrote:
>>>
>>> On Fri, Jan 10, 2014 at 06:02:23PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter
On 01/10/2014 01:54 PM, Andy Lutomirski wrote:
On Fri, Jan 10, 2014 at 9:41 AM, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 06:02:23PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
On 01/10/2014 12:02 PM, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
Peter,
Call Trace:
[] dump_stack+0x49/0x62
[] warn_slowpath_common+0x8c/0xc0
[] warn_slowpath_null+0x1a/0x20
[]
On Fri, Jan 10, 2014 at 9:41 AM, Peter Zijlstra wrote:
> On Fri, Jan 10, 2014 at 06:02:23PM +0100, Peter Zijlstra wrote:
>> On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter Zijlstra wrote:
>> > On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
>> > > Peter,
>> > >
>> > > Call Trace:
>>
On Fri, Jan 10, 2014 at 06:02:23PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter Zijlstra wrote:
> > On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
> > > Peter,
> > >
> > > Call Trace:
> > > [] dump_stack+0x49/0x62
> > > []
On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
> > Peter,
> >
> > Call Trace:
> > [] dump_stack+0x49/0x62
> > [] warn_slowpath_common+0x8c/0xc0
> > [] warn_slowpath_null+0x1a/0x20
> > []
On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
> Peter,
>
> Call Trace:
> [] dump_stack+0x49/0x62
> [] warn_slowpath_common+0x8c/0xc0
> [] warn_slowpath_null+0x1a/0x20
> [] force_sig_info+0x131/0x140
> [] force_sig_info_fault+0x5f/0x70
> [] ? search_exception_tables+0x2a/0x50
Peter,
I recently encountered a strange problem using 3.13-rc* kernel that
did not happen in a 3.12 kernel. When I ran the high_systime benchmark
of the AIM7 test suite, I saw the following errors:
Child terminated by signal #11
core dumped
Child terminated by signal #11
Child
Peter,
I recently encountered a strange problem using 3.13-rc* kernel that
did not happen in a 3.12 kernel. When I ran the high_systime benchmark
of the AIM7 test suite, I saw the following errors:
Child terminated by signal #11
core dumped
Child terminated by signal #11
Child
On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
Peter,
Call Trace:
NMI [815710af] dump_stack+0x49/0x62
[8104e3bc] warn_slowpath_common+0x8c/0xc0
[8104e40a] warn_slowpath_null+0x1a/0x20
[8105f1f1] force_sig_info+0x131/0x140
On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
Peter,
Call Trace:
NMI [815710af] dump_stack+0x49/0x62
[8104e3bc] warn_slowpath_common+0x8c/0xc0
[8104e40a]
On Fri, Jan 10, 2014 at 06:02:23PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
Peter,
Call Trace:
NMI [815710af] dump_stack+0x49/0x62
[8104e3bc]
On Fri, Jan 10, 2014 at 9:41 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Jan 10, 2014 at 06:02:23PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
Peter,
Call Trace:
On 01/10/2014 12:02 PM, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
Peter,
Call Trace:
NMI [815710af] dump_stack+0x49/0x62
[8104e3bc] warn_slowpath_common+0x8c/0xc0
On 01/10/2014 01:54 PM, Andy Lutomirski wrote:
On Fri, Jan 10, 2014 at 9:41 AM, Peter Zijlstrapet...@infradead.org wrote:
On Fri, Jan 10, 2014 at 06:02:23PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 10:29:13AM -0500,
On Fri, Jan 10, 2014 at 11:43 AM, Waiman Long waiman.l...@hp.com wrote:
On 01/10/2014 01:54 PM, Andy Lutomirski wrote:
On Fri, Jan 10, 2014 at 9:41 AM, Peter Zijlstrapet...@infradead.org
wrote:
On Fri, Jan 10, 2014 at 06:02:23PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at
On Fri, Jan 10, 2014 at 10:54:52AM -0800, Andy Lutomirski wrote:
Yuck -- when I wrote that thing, I hadn't imagined that an interrupt
(there's nothing particularly special about NMIs here, I think) would
try to access user memory. The fix below looks okay, but IMO it needs
a big fat comment
On Fri, Jan 10, 2014 at 02:37:10PM -0500, Waiman Long wrote:
@@ -641,7 +641,7 @@ no_context(struct pt_regs *regs, unsigned long
error_code,
/* Are we prepared to handle this kernel fault? */
if (fixup_exception(regs)) {
-if (current_thread_info()-sig_on_uaccess_error
On Fri, Jan 10, 2014 at 11:56:07AM -0800, Andy Lutomirski wrote:
- The perf callchain code tries to read from a bad userspace pointer
(not sure why -- the ip value in the vsyscall page *is* readable).
That traps (as expected), but the trap handler injects SIGSEGV due to
On Fri, Jan 10, 2014 at 12:06 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Jan 10, 2014 at 10:54:52AM -0800, Andy Lutomirski wrote:
Yuck -- when I wrote that thing, I hadn't imagined that an interrupt
(there's nothing particularly special about NMIs here, I think) would
try to access
26 matches
Mail list logo
