FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core
commit 7aba70e47ca4e961acb5af96d5127e3fad651c7c ("x86, perf: Optimize stack walk user accesses")
+-------------------------------------------------------+------------+------------+
| | a170cc71ef | 7aba70e47c |
+-------------------------------------------------------+------------+------------+
| boot_successes | 482 | 469 |
| boot_failures | 0 | 15 |
| BUG:unable_to_handle_kernel | 0 | 13 |
| Oops | 0 | 13 |
| EIP_is_at_perf_prepare_sample | 0 | 13 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 9 |
| backtrace:vfs_fstatat | 0 | 2 |
| backtrace:SyS_fstatat64 | 0 | 2 |
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 0 | 4 |
| WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page() | 0 | 2 |
| backtrace:mark_rodata_ro | 0 | 2 |
+-------------------------------------------------------+------------+------------+
[ 21.984049] BUG: unable to handle kernel paging request at 696d2f62
[ 21.986759] IP: [<4110c023>] perf_prepare_sample+0xcc/0x51d
[ 21.987859] *pdpt = 0000000001a93001 *pde = 0000000000000000
[ 21.988015] Oops: 0000 [#1] PREEMPT
[ 21.988015] Modules linked in:
[ 21.988015] CPU: 0 PID: 496 Comm: trinity-main Not tainted 4.3.0-01147-g7aba70e #1
[ 21.988015] task: 50979040 ti: 50d24000 task.ti: 50d24000
[ 21.988015] EIP: 0060:[<4110c023>] EFLAGS: 00010002 CPU: 0
[ 21.988015] EIP is at perf_prepare_sample+0xcc/0x51d
[ 21.988015] EAX: 696d2f62 EBX: 00000001 ECX: 00000002 EDX: 00000001
[ 21.988015] ESI: 50d25e20 EDI: 50d25d60 EBP: 50d25d44 ESP: 50d25d24
[ 21.988015] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[ 21.988015] CR0: 8005003b CR2: 696d2f62 CR3: 10da1a80 CR4: 000006b0
[ 21.988015] DR0: 370a1000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 21.988015] DR6: ffff0ff0 DR7: 000d0602
[ 21.988015] Stack:
[ 21.988015] 00000000 4110c474 00000000 000100b2 50de3800 50de3800 50d25e20 418a8d00
[ 21.988015] 50d25d8c 4110c4ae 418a8d00 00000002 00000000 00000000 4110c474 00000009
[ 21.988015] 00380001 00000000 00000001 00000000 50de3800 000c1459 00000000 50de3800
[ 21.988015] Call Trace:
[ 21.988015] [<4110c474>] ? perf_prepare_sample+0x51d/0x51d
[ 21.988015] [<4110c4ae>] perf_event_output+0x3a/0x9f
[ 21.988015] [<4110c474>] ? perf_prepare_sample+0x51d/0x51d
[ 21.988015] [<4110c787>] __perf_event_overflow+0x274/0x2e3
[ 21.988015] [<4110d206>] perf_swevent_overflow+0x76/0xa6
[ 21.988015] [<4110d382>] perf_swevent_event+0x14c/0x156
[ 21.988015] [<4110db88>] ___perf_sw_event+0x348/0x388
[ 21.988015] [<4108a2bd>] ? sched_clock_cpu+0x16d/0x193
[ 21.988015] [<4103f3ec>] ? pvclock_clocksource_read+0xb0/0x1a0
[ 21.988015] [<4108a34f>] ? local_clock+0x28/0x32
[ 21.988015] [<41095319>] ? __lock_acquire+0x2f4/0xa48
[ 21.988015] [<41093cbd>] ? __lock_is_held+0x2d/0x43
[ 21.988015] [<41093cbd>] ? __lock_is_held+0x2d/0x43
[ 21.988015] [<4144ce5e>] __schedule+0x785/0xc57
[ 21.988015] [<4108c79b>] ? pick_next_task_fair+0x19f/0x21a
[ 21.988015] [<4144ce5e>] ? __schedule+0x785/0xc57
[ 21.988015] [<4144d380>] schedule+0x50/0x78
[ 21.988015] [<4100133a>] exit_to_usermode_loop+0x4d/0x144
[ 21.988015] [<41001a94>] prepare_exit_to_usermode+0x50/0x56
[ 21.988015] [<41453fbf>] resume_userspace+0x13/0x18
[ 21.988015] [<41450000>] ? __ww_mutex_lock+0x253/0xaf0
[ 21.988015] Code: 45 f0 e8 9f 50 00 00 31 d2 85 c0 0f 95 c2 85 c0 8b 1c 95 04 4c 94 41 89 46 68 8d 4b 01 89 0c 95 04 4c 94 41 ba 01 00 00 00 74 03 <8b> 10 42 66 c1 e2 03 66 01 57 06 8b 55 ec 31 c0 81 e2 00 04 00
[ 21.988015] EIP: [<4110c023>] perf_prepare_sample+0xcc/0x51d SS:ESP 0068:50d25d24
[ 21.988015] CR2: 00000000696d2f62
[ 21.988015] ---[ end trace 5e43f9815ea3ff0d ]---
[ 21.988015] Kernel panic - not syncing: Fatal exception
[ 21.988015] Kernel Offset: disabled
Thanks,
Ying Huang
On Wed, Nov 18, 2015 at 02:33:00PM +0800, kernel test robot wrote:
> FYI, we noticed the below changes on
>
> https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core
> commit 7aba70e47ca4e961acb5af96d5127e3fad651c7c ("x86, perf: Optimize stack walk user accesses")
Of course, that commit no longer exists. I re-create the tree every time
I push it, this means that if you report something a few days later, its
highly likely its against non-existant commits :/
> [ 21.984049] BUG: unable to handle kernel paging request at 696d2f62
> [ 21.986759] IP: [<4110c023>] perf_prepare_sample+0xcc/0x51d
> [ 21.987859] *pdpt = 0000000001a93001 *pde = 0000000000000000
> [ 21.988015] Oops: 0000 [#1] PREEMPT
> [ 21.988015] Modules linked in:
> [ 21.988015] CPU: 0 PID: 496 Comm: trinity-main Not tainted 4.3.0-01147-g7aba70e #1
That doesn't actually look like something the fingered patch touches.
And seeing how its trinity triggering it, I suspect bisection fail.
Hi, Peter,
Peter Zijlstra <[email protected]> writes:
> On Wed, Nov 18, 2015 at 02:33:00PM +0800, kernel test robot wrote:
>> FYI, we noticed the below changes on
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core
>> commit 7aba70e47ca4e961acb5af96d5127e3fad651c7c ("x86, perf: Optimize stack walk user accesses")
>
> Of course, that commit no longer exists. I re-create the tree every time
> I push it, this means that if you report something a few days later, its
> highly likely its against non-existant commits :/
I am sorry about this. We will try our best to reach real 0day
reporting.
>> [ 21.984049] BUG: unable to handle kernel paging request at 696d2f62
>> [ 21.986759] IP: [<4110c023>] perf_prepare_sample+0xcc/0x51d
>> [ 21.987859] *pdpt = 0000000001a93001 *pde = 0000000000000000
>> [ 21.988015] Oops: 0000 [#1] PREEMPT
>> [ 21.988015] Modules linked in:
>> [ 21.988015] CPU: 0 PID: 496 Comm: trinity-main Not tainted 4.3.0-01147-g7aba70e #1
>
> That doesn't actually look like something the fingered patch touches.
> And seeing how its trinity triggering it, I suspect bisection fail.
Thanks for reminding, we will check the bisection process.
Best Regards,
Huang, Ying
On Thu, Nov 19, 2015 at 08:38:58AM +0800, Huang, Ying wrote:
> Hi, Peter,
>
> Peter Zijlstra <[email protected]> writes:
>
> > On Wed, Nov 18, 2015 at 02:33:00PM +0800, kernel test robot wrote:
> >> FYI, we noticed the below changes on
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core
> >> commit 7aba70e47ca4e961acb5af96d5127e3fad651c7c ("x86, perf: Optimize stack walk user accesses")
> >
> > Of course, that commit no longer exists. I re-create the tree every time
> > I push it, this means that if you report something a few days later, its
> > highly likely its against non-existant commits :/
>
> I am sorry about this. We will try our best to reach real 0day
> reporting.
Is there any way I can monitor the progress of a given tree through the
whole 0-day testing farm? I know the various compile tests are complete
because those send email. But after that it goes off into magic land
without further feedback, unless something bad happens as per this
report.
It would be useful for me to know how far along a given tree is before I
zap it.
On Wed, Nov 18, 2015 at 05:27:42PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 18, 2015 at 02:33:00PM +0800, kernel test robot wrote:
> > FYI, we noticed the below changes on
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core
> > commit 7aba70e47ca4e961acb5af96d5127e3fad651c7c ("x86, perf: Optimize stack walk user accesses")
>
> Of course, that commit no longer exists. I re-create the tree every time
> I push it, this means that if you report something a few days later, its
> highly likely its against non-existant commits :/
>
> > [ 21.984049] BUG: unable to handle kernel paging request at 696d2f62
> > [ 21.986759] IP: [<4110c023>] perf_prepare_sample+0xcc/0x51d
> > [ 21.987859] *pdpt = 0000000001a93001 *pde = 0000000000000000
> > [ 21.988015] Oops: 0000 [#1] PREEMPT
> > [ 21.988015] Modules linked in:
> > [ 21.988015] CPU: 0 PID: 496 Comm: trinity-main Not tainted 4.3.0-01147-g7aba70e #1
>
> That doesn't actually look like something the fingered patch touches.
> And seeing how its trinity triggering it, I suspect bisection fail.
Ok. I assume it's not caused by my patch. Let me know if that is wrong.
I also pushed the patch before to my tree (which is 0day tested) and there
was no such report (but of course trinity is somewhat random).
BTW if you're going to test trinity for perf it may be better to use
Vince Weaver's version here
https://github.com/deater/perf_event_tests
which has more coverage for perf than normal trinity.
-Andi
--
[email protected] -- Speaking for myself only
Hi, Andi,
Andi Kleen <[email protected]> writes:
> On Wed, Nov 18, 2015 at 05:27:42PM +0100, Peter Zijlstra wrote:
>> On Wed, Nov 18, 2015 at 02:33:00PM +0800, kernel test robot wrote:
>> > FYI, we noticed the below changes on
>> >
>> > https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core
>> > commit 7aba70e47ca4e961acb5af96d5127e3fad651c7c ("x86, perf: Optimize stack walk user accesses")
>>
>> Of course, that commit no longer exists. I re-create the tree every time
>> I push it, this means that if you report something a few days later, its
>> highly likely its against non-existant commits :/
>>
>> > [ 21.984049] BUG: unable to handle kernel paging request at 696d2f62
>> > [ 21.986759] IP: [<4110c023>] perf_prepare_sample+0xcc/0x51d
>> > [ 21.987859] *pdpt = 0000000001a93001 *pde = 0000000000000000
>> > [ 21.988015] Oops: 0000 [#1] PREEMPT
>> > [ 21.988015] Modules linked in:
>> > [ 21.988015] CPU: 0 PID: 496 Comm: trinity-main Not tainted 4.3.0-01147-g7aba70e #1
>>
>> That doesn't actually look like something the fingered patch touches.
>> And seeing how its trinity triggering it, I suspect bisection fail.
>
> Ok. I assume it's not caused by my patch. Let me know if that is wrong.
Sorry about false positive.
> I also pushed the patch before to my tree (which is 0day tested) and there
> was no such report (but of course trinity is somewhat random).
>
> BTW if you're going to test trinity for perf it may be better to use
> Vince Weaver's version here
>
> https://github.com/deater/perf_event_tests
>
> which has more coverage for perf than normal trinity.
Thanks for your information. We will integrate it into 0day tests.
Best Regards,
Huang, Ying
Hi, Peter,
Peter Zijlstra <[email protected]> writes:
> On Thu, Nov 19, 2015 at 08:38:58AM +0800, Huang, Ying wrote:
>> Hi, Peter,
>>
>> Peter Zijlstra <[email protected]> writes:
>>
>> > On Wed, Nov 18, 2015 at 02:33:00PM +0800, kernel test robot wrote:
>> >> FYI, we noticed the below changes on
>> >>
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git perf/core
>> >> commit 7aba70e47ca4e961acb5af96d5127e3fad651c7c ("x86, perf: Optimize stack walk user accesses")
>> >
>> > Of course, that commit no longer exists. I re-create the tree every time
>> > I push it, this means that if you report something a few days later, its
>> > highly likely its against non-existant commits :/
>>
>> I am sorry about this. We will try our best to reach real 0day
>> reporting.
>
> Is there any way I can monitor the progress of a given tree through the
> whole 0-day testing farm? I know the various compile tests are complete
> because those send email. But after that it goes off into magic land
> without further feedback, unless something bad happens as per this
> report.
>
> It would be useful for me to know how far along a given tree is before I
> zap it.
So far, we have no such features like 'boot/functionality/performance
test complete' or progress report email. But I think that could be a
useful features for many people. We will add it to the TODO of 0day.
Best Regards,
Huang, Ying