Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1256560 > unrolled thread

perf oops/recursive fault using BTS

Started byDave Jones <davej@codemonkey.org.uk>
First post2015-10-27 09:30 +0100
Last post2015-10-27 23:10 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

Contents

  perf oops/recursive fault using BTS Dave Jones <davej@codemonkey.org.uk> - 2015-10-27 09:30 +0100
    Re: perf oops/recursive fault using BTS Vince Weaver <vincent.weaver@maine.edu> - 2015-10-27 20:00 +0100
      Re: perf oops/recursive fault using BTS Dave Jones <davej@codemonkey.org.uk> - 2015-10-27 23:10 +0100

#1256560 — perf oops/recursive fault using BTS

FromDave Jones <davej@codemonkey.org.uk>
Date2015-10-27 09:30 +0100
Subjectperf oops/recursive fault using BTS
Message-ID<qo7NM-2U1-15@gated-at.bofh.it>
I was experimenting with a variant of Vince's bts_kernel test
(https://github.com/deater/perf_event_tests/blob/master/tests/x86_intel/bts_kernel.c)
and hit this..

Oops: 0000 [#1] PREEMPT SMP 
CPU: 3 PID: 2471 Comm: a.out Not tainted 4.3.0-rc6-wopr+ #1 
task: ffff8805f0b3e400 ti: ffff8801f81d4000 task.ti: ffff8801f81d4000
RIP: 0010:[<ffffffff9d13e44c>]  [<ffffffff9d13e44c>] perf_mmap_close+0x3c/0x250
RSP: 0000:ffff8801f81d7b78  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 000000000952ecf3 RSI: ffff88082fc78ea0 RDI: ffff8808026de800
RBP: ffff8801f81d7bc8 R08: 0000000000018ea0 R09: ffff88080c201000
R10: ffffea00151ae460 R11: 0000000000000000 R12: ffff8807071d2000
R13: ffff8808026de800 R14: ffff8807071d2678 R15: ffff8805f0b3e400
FS:  0000000000000000(0000) GS:ffff88082fc60000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000c0 CR3: 000000001dc0b000 CR4: 00000000001406e0
Stack:
 ffff8801f81d7c00 ffff8805f0b3e9f8 ffff8807ed482de8 ffff8805f0b3e400
 00000000c88a8a46 ffff8807071d2678 ffff8807071d2000 ffff8805f0b3e9f8
 ffff8807ed482de8 ffff8805f0b3e400 ffff8801f81d7be8 ffffffff9d17852a
Call Trace:
 [<ffffffff9d17852a>] remove_vma+0x2a/0x60
 [<ffffffff9d17bdfd>] exit_mmap+0x12d/0x160
 [<ffffffff9d07040f>] mmput+0x4f/0xf0
 [<ffffffff9d07458e>] do_exit+0x31e/0xaa0
 [<ffffffff9d075b53>] do_group_exit+0x43/0xb0
 [<ffffffff9d080deb>] get_signal+0x23b/0x640
 [<ffffffff9d003b97>] do_signal+0x37/0x6b0
 [<ffffffff9d03e306>] ? force_sig_info_fault.constprop.23+0x76/0x90
 [<ffffffff9d090000>] ? kthread_bind+0x40/0x40
 [<ffffffff9d03e356>] ? is_prefetch.isra.18+0x36/0x260
 [<ffffffff9d090000>] ? kthread_bind+0x40/0x40
 [<ffffffff9d03eeb0>] ? mm_fault_error+0x110/0x130
 [<ffffffff9d03f30a>] ? __do_page_fault+0x43a/0x470
 [<ffffffff9d001b06>] prepare_exit_to_usermode+0xb6/0x110
 [<ffffffff9d6c76ea>] retint_user+0x8/0x1d
Code: 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 48 8b 87 a0 00 00 00 4c 8b a8 c8 00 00 00 4c 89 ef e8 57 ec ff ff 48 89 c3 <48> 8b 80 c0 00 00 00 48 89 45 c0 48 8b 83 b8 00 00 00 48 89 45 
RIP  [<ffffffff9d13e44c>] perf_mmap_close+0x3c/0x250
 RSP <ffff8801f81d7b78>
CR2: 00000000000000c0
---[ end trace 9362dce880c51b19 ]---
Fixing recursive fault but reboot is needed!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1257128

FromVince Weaver <vincent.weaver@maine.edu>
Date2015-10-27 20:00 +0100
Message-ID<qohDs-j5-5@gated-at.bofh.it>
In reply to#1256560
On Tue, 27 Oct 2015, Dave Jones wrote:

> I was experimenting with a variant of Vince's bts_kernel test
> (https://github.com/deater/perf_event_tests/blob/master/tests/x86_intel/bts_kernel.c)
> and hit this..

what type of machine was this on?  

I'm cc-ing the perf developers because I'm not sure if they monitor 
linux-kernel directly.


Vince

> 
> Oops: 0000 [#1] PREEMPT SMP 
> CPU: 3 PID: 2471 Comm: a.out Not tainted 4.3.0-rc6-wopr+ #1 
> task: ffff8805f0b3e400 ti: ffff8801f81d4000 task.ti: ffff8801f81d4000
> RIP: 0010:[<ffffffff9d13e44c>]  [<ffffffff9d13e44c>] perf_mmap_close+0x3c/0x250
> RSP: 0000:ffff8801f81d7b78  EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 000000000952ecf3 RSI: ffff88082fc78ea0 RDI: ffff8808026de800
> RBP: ffff8801f81d7bc8 R08: 0000000000018ea0 R09: ffff88080c201000
> R10: ffffea00151ae460 R11: 0000000000000000 R12: ffff8807071d2000
> R13: ffff8808026de800 R14: ffff8807071d2678 R15: ffff8805f0b3e400
> FS:  0000000000000000(0000) GS:ffff88082fc60000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000000000c0 CR3: 000000001dc0b000 CR4: 00000000001406e0
> Stack:
>  ffff8801f81d7c00 ffff8805f0b3e9f8 ffff8807ed482de8 ffff8805f0b3e400
>  00000000c88a8a46 ffff8807071d2678 ffff8807071d2000 ffff8805f0b3e9f8
>  ffff8807ed482de8 ffff8805f0b3e400 ffff8801f81d7be8 ffffffff9d17852a
> Call Trace:
>  [<ffffffff9d17852a>] remove_vma+0x2a/0x60
>  [<ffffffff9d17bdfd>] exit_mmap+0x12d/0x160
>  [<ffffffff9d07040f>] mmput+0x4f/0xf0
>  [<ffffffff9d07458e>] do_exit+0x31e/0xaa0
>  [<ffffffff9d075b53>] do_group_exit+0x43/0xb0
>  [<ffffffff9d080deb>] get_signal+0x23b/0x640
>  [<ffffffff9d003b97>] do_signal+0x37/0x6b0
>  [<ffffffff9d03e306>] ? force_sig_info_fault.constprop.23+0x76/0x90
>  [<ffffffff9d090000>] ? kthread_bind+0x40/0x40
>  [<ffffffff9d03e356>] ? is_prefetch.isra.18+0x36/0x260
>  [<ffffffff9d090000>] ? kthread_bind+0x40/0x40
>  [<ffffffff9d03eeb0>] ? mm_fault_error+0x110/0x130
>  [<ffffffff9d03f30a>] ? __do_page_fault+0x43a/0x470
>  [<ffffffff9d001b06>] prepare_exit_to_usermode+0xb6/0x110
>  [<ffffffff9d6c76ea>] retint_user+0x8/0x1d
> Code: 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 48 8b 87 a0 00 00 00 4c 8b a8 c8 00 00 00 4c 89 ef e8 57 ec ff ff 48 89 c3 <48> 8b 80 c0 00 00 00 48 89 45 c0 48 8b 83 b8 00 00 00 48 89 45 
> RIP  [<ffffffff9d13e44c>] perf_mmap_close+0x3c/0x250
>  RSP <ffff8801f81d7b78>
> CR2: 00000000000000c0
> ---[ end trace 9362dce880c51b19 ]---
> Fixing recursive fault but reboot is needed!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1257394

FromDave Jones <davej@codemonkey.org.uk>
Date2015-10-27 23:10 +0100
Message-ID<qokBk-2oh-43@gated-at.bofh.it>
In reply to#1257128
On Tue, Oct 27, 2015 at 02:58:49PM -0400, Vince Weaver wrote:
 > On Tue, 27 Oct 2015, Dave Jones wrote:
 > 
 > > I was experimenting with a variant of Vince's bts_kernel test
 > > (https://github.com/deater/perf_event_tests/blob/master/tests/x86_intel/bts_kernel.c)
 > > and hit this..
 > 
 > what type of machine was this on?  
 > 

i7-5820K

	Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web