* [PATCH] perf/core: Fix to check perf_cpu_time_max_percent
@ 2017-02-23 6:04 Tan Xiaojun
2017-02-24 9:15 ` [tip:perf/urgent] perf/core: Fix the perf_cpu_time_max_percent check tip-bot for Tan Xiaojun
0 siblings, 1 reply; 8+ messages in thread
From: Tan Xiaojun @ 2017-02-23 6:04 UTC (permalink / raw)
To: peterz, mingo, acme, alexander.shishkin; +Cc: linux-kernel
Use "proc_dointvec_minmax" instead of "proc_dointvec" to check the input
value from userspace.
If not, we can set a big value and some vars will overflow like
"sysctl_perf_event_sample_rate". And it will cause a lot of unexpected
problems.
When I found this problem, I was doing the perf_fuzzer test in Hisilicon
D03. And get logs below(from console):
**********************************************************
[ 90.880860] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 90.896873] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 91.884088] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 96.466762] perf: interrupt took too long (46 > 1), lowering kernel.perf_event_max_sample_rate to 175250
[ 96.476228] perf: interrupt took too long (68 > 57), lowering kernel.perf_event_max_sample_rate to 117500
[ 96.485774] perf: interrupt took too long (97 > 85), lowering kernel.perf_event_max_sample_rate to 82500
[ 96.495249] perf: interrupt took too long (145 > 121), lowering kernel.perf_event_max_sample_rate to 55000
[ 96.737083] perf: interrupt took too long (194 > 181), lowering kernel.perf_event_max_sample_rate to 41250
[ 96.762287] perf: interrupt took too long (281 > 242), lowering kernel.perf_event_max_sample_rate to 28250
[ 96.784693] perf: interrupt took too long (369 > 351), lowering kernel.perf_event_max_sample_rate to 21500
[ 98.094492] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 99.550597] perf: interrupt took too long (10 > 1), lowering kernel.perf_event_max_sample_rate to -383141598
[ 99.576690] perf: interrupt took too long (15 > 12), lowering kernel.perf_event_max_sample_rate to -1687083664
[ 99.602955] perf: interrupt took too long (21 > 18), lowering kernel.perf_event_max_sample_rate to -176834776
[ 99.629749] perf: interrupt took too long (32 > 26), lowering kernel.perf_event_max_sample_rate to -544439184
[ 99.656491] perf: interrupt took too long (48 > 40), lowering kernel.perf_event_max_sample_rate to -1794615388
[ 99.689272] perf: interrupt took too long (66 > 60), lowering kernel.perf_event_max_sample_rate to -475090842
[ 101.823705] perf: interrupt took too long (1932 > 1), lowering kernel.perf_event_max_sample_rate to 8250
[ 102.368030] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 105.872880] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 138.222411] perf: interrupt took too long (449 > 1), lowering kernel.perf_event_max_sample_rate to 1858059000
[ 159.219465] INFO: rcu_preempt self-detected stall on CPU
[ 159.224774] 8-...: (4 GPs behind) idle=dab/140000000000002/0 softirq=18839/18840 fqs=2625
[ 159.227465] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 159.227470] 8-...: (4 GPs behind) idle=dab/140000000000002/0 softirq=18839/18840 fqs=2625
[ 159.227471] (detected by 5, t=5252 jiffies, g=7249, c=7248, q=314)
[ 159.227476] Task dump for CPU 8:
[ 159.227477] perf_fuzzer R running task 0 11327 4975 0x00000203
[ 159.227481] Call trace:
[ 159.227487] [<ffff000008082eb0>] ret_from_fork+0x0/0x50
[ 159.271265] (t=5262 jiffies g=7249 c=7248 q=314)
[ 159.276055] Task dump for CPU 8:
[ 159.279283] perf_fuzzer R running task 0 11327 4975 0x00000203
[ 159.286317] Call trace:
[ 159.288773] [<ffff0000080883d4>] dump_backtrace+0x0/0x240
[ 159.294167] [<ffff000008088628>] show_stack+0x14/0x1c
[ 159.299215] [<ffff0000080e5f84>] sched_show_task+0x130/0x174
[ 159.304866] [<ffff0000080e8948>] dump_cpu_task+0x40/0x4c
[ 159.310171] [<ffff00000816f944>] rcu_dump_cpu_stacks+0xa4/0xec
[ 159.315996] [<ffff00000811a160>] rcu_check_callbacks+0x9d8/0xc70
[ 159.321992] [<ffff00000811e0e8>] update_process_times+0x2c/0x58
[ 159.327893] [<ffff00000812d1cc>] tick_sched_handle.isra.17+0x20/0x60
[ 159.334234] [<ffff00000812d250>] tick_sched_timer+0x44/0x88
[ 159.339799] [<ffff00000811e980>] __hrtimer_run_queues+0xe8/0x14c
[ 159.345795] [<ffff00000811ef04>] hrtimer_interrupt+0x9c/0x1e0
[ 159.351536] [<ffff000008793a94>] arch_timer_handler_virt+0x2c/0x38
[ 159.357708] [<ffff00000810f554>] handle_percpu_devid_irq+0x78/0x12c
[ 159.363967] [<ffff00000810a5ec>] generic_handle_irq+0x24/0x38
[ 159.369705] [<ffff00000810ac84>] __handle_domain_irq+0x60/0xac
[ 159.375526] [<ffff0000080816e4>] gic_handle_irq+0x74/0x174
[ 159.381003] Exception stack(0xffff803ffff34df0 to 0xffff803ffff34f20)
[ 159.387429] 4de0: ffff803ffff34e20 0001000000000000
[ 159.395241] 4e00: ffff803ffff34f50 ffff0000080c29b0 0000000040000145 000000000000001b
[ 159.403052] 4e20: 0000000000000400 ffff000008ed3300 ffff000008ed3300 0000803ff7196000
[ 159.410864] 4e40: 000000000ccccccd 0000000000000020 000dc56c20000000 0000000000000032
[ 159.418676] 4e60: 000000000000002e 000000003b9aca00 000000000000000d 656b20676e697265
[ 159.426487] 4e80: 7265702e6c656e72 5f746e6576655f66 ffff000008ba6000 0000803ff7196000
[ 159.434299] 4ea0: 000000000042c778 0000000000001c51 0000fffff3b48c50 ffff000008d9b000
[ 159.442111] 4ec0: 0000000000000000 ffff000008d9fb08 ffff000008d9b000 ffff000008bc5728
[ 159.449923] 4ee0: 000000000000001b ffff000008ba1000 ffff803ffff35090 0000000000000202
[ 159.457734] 4f00: ffff803f6efbe400 ffff803ffff34f50 ffff0000080c2e40 ffff803ffff34f50
[ 159.465550] [<ffff0000080827f4>] el1_irq+0xb4/0x128
[ 159.470422] [<ffff0000080c2e40>] irq_exit+0xd0/0x118
[ 159.475382] [<ffff00000810ac88>] __handle_domain_irq+0x64/0xac
[ 159.481205] [<ffff0000080816e4>] gic_handle_irq+0x74/0x174
[ 159.486684] Exception stack(0xffff803f70bfbec0 to 0xffff803f70bfbff0)
[ 159.493115] bec0: 000000000000136f 0000000000000000 0000000000014f4b 0000ffff8233c5f0
[ 159.500927] bee0: 0000ffff8233b270 0000000000000000 0000ffff823636f0 0000000000000000
[ 159.508740] bf00: 00000000000000ad 00000000ffffff80 0000000000000001 0000fffff3b48e10
[ 159.516552] bf20: 0000000000000000 0000000100000000 0000000000000000 00004a51a0000000
[ 159.524365] bf40: 000000000042c778 0000ffff82266c70 0000fffff3b48c50 0000000000414bd0
[ 159.532176] bf60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 159.539988] bf80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 159.547799] bfa0: 0000000000000000 0000fffff3b48e60 0000000000409264 0000fffff3b48e60
[ 159.555614] bfc0: 0000000000410a14 0000000020000000 0000000000000000 ffffffffffffffff
[ 159.563425] bfe0: 0000000000000000 0000000000000000
[ 159.568296] [<ffff000008082d18>] el0_irq_naked+0x4c/0x54
[ 185.429581] NMI watchdog: BUG: soft lockup - CPU#8 stuck for 22s! [perf_fuzzer:11327]
[ 185.437397] Modules linked in:
[ 185.440454]
[ 185.441956] CPU: 8 PID: 11327 Comm: perf_fuzzer Not tainted 4.10.0-rc1-ga1d2732-dirty #5
[ 185.450028] Hardware name: Huawei Taishan 2180 /BC11SPCC, BIOS 1.31 06/23/2016
[ 185.457235] task: ffff803f6efbe400 task.stack: ffff803f70bf8000
[ 185.463149] PC is at __do_softirq+0xc0/0x240
[ 185.467416] LR is at irq_exit+0xd0/0x118
[ 185.471340] pc : [<ffff0000080c29b0>] lr : [<ffff0000080c2e40>] pstate: 40000145
[ 185.478719] sp : ffff803ffff34f50
[ 185.482033] x29: ffff803ffff34f50 x28: ffff803f6efbe400
[ 185.487339] x27: 0000000000000202 x26: ffff803ffff35090
[ 185.492646] x25: ffff000008ba1000 x24: 000000000000001b
[ 185.497952] x23: ffff000008bc5728 x22: ffff000008d9b000
[ 185.503259] x21: ffff000008d9fb08 x20: 0000000000000000
[ 185.508566] x19: ffff000008d9b000 x18: 0000fffff3b48c50
[ 185.513872] x17: 0000000000001c51 x16: 000000000042c778
[ 185.519180] x15: 0000803ff7196000 x14: ffff000008ba6000
[ 185.524483] x13: 5f746e6576655f66 x12: 7265702e6c656e72
[ 185.529790] x11: 656b20676e697265 x10: 000000000000000d
[ 185.535093] x9 : 000000003b9aca00 x8 : 000000000000002e
[ 185.540400] x7 : 0000000000000032 x6 : 000dc56c20000000
[ 185.545707] x5 : 0000000000000020 x4 : 000000000ccccccd
[ 185.551010] x3 : 0000803ff7196000 x2 : ffff000008ed3300
[ 185.556313] x1 : ffff000008ed3300 x0 : 0000000000000400
[ 185.561619]
**********************************************************
Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
---
kernel/events/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 77a932b..53b1747 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -455,7 +455,7 @@ int perf_cpu_time_max_percent_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp,
loff_t *ppos)
{
- int ret = proc_dointvec(table, write, buffer, lenp, ppos);
+ int ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
if (ret || !write)
return ret;
--
1.9.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [tip:perf/urgent] perf/core: Fix the perf_cpu_time_max_percent check
2017-02-23 6:04 [PATCH] perf/core: Fix to check perf_cpu_time_max_percent Tan Xiaojun
@ 2017-02-24 9:15 ` tip-bot for Tan Xiaojun
2017-02-25 8:10 ` Tan Xiaojun
0 siblings, 1 reply; 8+ messages in thread
From: tip-bot for Tan Xiaojun @ 2017-02-24 9:15 UTC (permalink / raw)
To: linux-tip-commits
Cc: tanxiaojun, acme, peterz, torvalds, tglx, vincent.weaver,
eranian, linux-kernel, acme, hpa, mingo, jolsa,
alexander.shishkin
Commit-ID: 1572e45a924f254d9570093abde46430c3172e3d
Gitweb: http://git.kernel.org/tip/1572e45a924f254d9570093abde46430c3172e3d
Author: Tan Xiaojun <tanxiaojun@huawei.com>
AuthorDate: Thu, 23 Feb 2017 14:04:39 +0800
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 24 Feb 2017 08:56:33 +0100
perf/core: Fix the perf_cpu_time_max_percent check
Use "proc_dointvec_minmax" instead of "proc_dointvec" to check the input
value from user-space.
If not, we can set a big value and some vars will overflow like
"sysctl_perf_event_sample_rate" which will cause a lot of unexpected
problems.
Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <acme@kernel.org>
Cc: <alexander.shishkin@linux.intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Link: http://lkml.kernel.org/r/1487829879-56237-1-git-send-email-tanxiaojun@huawei.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
kernel/events/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index d4e3f8d..c1c1cdf 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -455,7 +455,7 @@ int perf_cpu_time_max_percent_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp,
loff_t *ppos)
{
- int ret = proc_dointvec(table, write, buffer, lenp, ppos);
+ int ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
if (ret || !write)
return ret;
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [tip:perf/urgent] perf/core: Fix the perf_cpu_time_max_percent check
2017-02-24 9:15 ` [tip:perf/urgent] perf/core: Fix the perf_cpu_time_max_percent check tip-bot for Tan Xiaojun
@ 2017-02-25 8:10 ` Tan Xiaojun
2017-02-25 9:51 ` Peter Zijlstra
0 siblings, 1 reply; 8+ messages in thread
From: Tan Xiaojun @ 2017-02-25 8:10 UTC (permalink / raw)
To: jolsa, alexander.shishkin, eranian, hpa, mingo, linux-kernel,
acme, peterz, acme, vincent.weaver, tglx, torvalds,
linux-tip-commits, vincent.weaver
Cc: linux-arm-kernel
Hi, Peter:
First, thank you for your approval of my last patch and fix my bad description. And I have some questions about perf event and perf_fuzzer.
Recently I was using perf_fuzzer for testing in Hisilicon D03/D05(arm64, linux-4.10-rc1).
As we know perf_fuzzer will write a random value to procfs interface of perf event(like sysctl_perf_cpu_time_max_percent). The value may be 0 or 100, and I get logs like below:
----------------------------------
[ 4046.358811] perf: Dynamic interrupt throttling disabled, can hang your system!
----------------------------------
Most of the time, there is no problem, and the perf_fuzzer test can end without any warings or errors.
But there is a small probability that triggers the RCU and watchdog (The log is attached at the end). It hungs after local_irq_enable() in __do_softirq.
I think this is due to the dynamic interrupt throttling disabled and too many hardware interruptions come. So I limit the sysctl_perf_cpu_time_max_percent can only be set 1 to 99 in the kernel codes. I test more than 20 times in D03, and there are no errors or warnings in the test.
So I want to ask:
1)Is it a problem or not? (It has already given you a warning.)
2)If it is, where we will fix it more appropriate, perf_fuzzer(not set 0 or 100) or kernel(limit 1 to 99), or maybe it is the bug of hardware(too many hardware interruptions)?
Thanks.
Xiaojun.
------------------------------------
[ 3831.245881] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 3844.421731] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 4032.764228] hrtimer: interrupt took 2280 ns
[ 4035.494181] perf: interrupt took too long (1444 > 1), lowering kernel.perf_event_max_sample_rate to 16500
[ 4040.292886] perf: interrupt took too long (5 > 1), lowering kernel.perf_event_max_sample_rate to 5000000
[ 4041.388784] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 4046.358811] perf: Dynamic interrupt throttling disabled, can hang your system!
10-175-112-211:~ #
10-175-112-211:~ #
10-175-112-211:~ # [ 4270.928905] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 4270.945154] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 4271.906280] perf: Dynamic interrupt throttling disabled, can hang your system!
[ 4294.491755] INFO: rcu_preempt self-detected stall on CPU
[ 4294.495755] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 4294.495761] 14-...: (6 GPs behind) idle=d65/140000000000002/0 softirq=6173/6173 fqs=2566
[ 4294.495761] (detected by 7, t=5252 jiffies, g=58964, c=58963, q=186)
[ 4294.495766] Task dump for CPU 14:
[ 4294.495768] perf_fuzzer R running task 0 31306 5036 0x00000202
[ 4294.495771] Call trace:
[ 4294.495778] [<ffff000008085634>] __switch_to+0x8c/0xac
[ 4294.495783] [<ffff00000815ef38>] event_function_call+0x88/0xf0
[ 4294.495785] [<ffff00000815f058>] _perf_event_enable+0x54/0x80
[ 4294.495788] [<ffff00000815ea2c>] perf_event_for_each_child+0x38/0x98
[ 4294.495791] [<ffff000008166a48>] perf_event_task_enable+0x58/0xa0
[ 4294.495794] [<ffff0000080d11e0>] SyS_prctl+0x2a0/0x3fc
[ 4294.495796] [<ffff000008082f8c>] __sys_trace_return+0x0/0x4
[ 4294.569983] 14-...: (6 GPs behind) idle=d65/140000000000002/0 softirq=6173/6173 fqs=2576
[ 4294.578228] (t=5272 jiffies g=58964 c=58963 q=186)
[ 4294.583187] Task dump for CPU 14:
[ 4294.586505] perf_fuzzer R running task 0 31306 5036 0x00000202
[ 4294.593541] Call trace:
[ 4294.595995] [<ffff0000080883d4>] dump_backtrace+0x0/0x240
[ 4294.601388] [<ffff000008088628>] show_stack+0x14/0x1c
[ 4294.606435] [<ffff0000080e5f84>] sched_show_task+0x130/0x174
[ 4294.612087] [<ffff0000080e8948>] dump_cpu_task+0x40/0x4c
[ 4294.617391] [<ffff00000816f944>] rcu_dump_cpu_stacks+0xa4/0xec
[ 4294.623215] [<ffff00000811a160>] rcu_check_callbacks+0x9d8/0xc70
[ 4294.629212] [<ffff00000811e0e8>] update_process_times+0x2c/0x58
[ 4294.635124] [<ffff00000812d1cc>] tick_sched_handle.isra.17+0x20/0x60
[ 4294.641465] [<ffff00000812d250>] tick_sched_timer+0x44/0x88
[ 4294.647027] [<ffff00000811e980>] __hrtimer_run_queues+0xe8/0x14c
[ 4294.653024] [<ffff00000811ef04>] hrtimer_interrupt+0x9c/0x1e0
[ 4294.658766] [<ffff000008793a94>] arch_timer_handler_virt+0x2c/0x38
[ 4294.664938] [<ffff00000810f554>] handle_percpu_devid_irq+0x78/0x12c
[ 4294.671195] [<ffff00000810a5ec>] generic_handle_irq+0x24/0x38
[ 4294.676932] [<ffff00000810ac84>] __handle_domain_irq+0x60/0xac
[ 4294.682756] [<ffff0000080816e4>] gic_handle_irq+0x74/0x174
[ 4294.688234] Exception stack(0xffff803ffffb2df0 to 0xffff803ffffb2f20)
[ 4294.694664] 2de0: ffff803ffffb2e20 0001000000000000
[ 4294.702480] 2e00: ffff803ffffb2f50 ffff0000080c29b0 0000000040000145 000000000000001b
[ 4294.710291] 2e20: 0000000000000700 ffff000008ed3300 ffff000008ed3300 0000803ff7214000
[ 4294.718106] 2e40: 000000000ccccccd 0000000000000020 001df84284000000 0000000001572fe1
[ 4294.725917] 2e60: 0000000000000000 0000000000000002 0000000000000002 0000ffffda3b0880
[ 4294.733729] 2e80: 0000000000000018 00000003e8000000 ffff000008ba6000 0000803ff7214000
[ 4294.741544] 2ea0: ffff0000080d0f40 000000000000e654 0000ffffda3b0690 ffff000008d9b000
[ 4294.749357] 2ec0: 0000000000000000 ffff000008d9fb08 ffff000008d9b000 ffff000008bc5728
[ 4294.757172] 2ee0: 000000000000001b ffff000008ba1000 ffff803ffffb3090 0000000000000282
[ 4294.764983] 2f00: ffff803f6e7bb200 ffff803ffffb2f50 ffff0000080c2e40 ffff803ffffb2f50
[ 4294.772798] [<ffff0000080827f4>] el1_irq+0xb4/0x128
[ 4294.777673] [<ffff0000080c2e40>] irq_exit+0xd0/0x118
[ 4294.782632] [<ffff00000810ac88>] __handle_domain_irq+0x64/0xac
[ 4294.788456] [<ffff0000080816e4>] gic_handle_irq+0x74/0x174
[ 4294.793934] Exception stack(0xffff803f5c07fbb0 to 0xffff803f5c07fce0)
[ 4294.800362] fba0: 0000000000000000 ffff803f6e7bb200
[ 4294.808177] fbc0: 0000000000008d5b 00000000000001c0 0000000000000000 0000000000000006
[ 4294.815992] fbe0: 0000000000000015 00000000dc7d24d2 00000000000000a7 00000000ffffff80
[ 4294.823803] fc00: 00000000ffffffd0 0000ffffda3b0880 0000000000000018 00000003e8000000
[ 4294.831618] fc20: 00028d3784000000 000069ade8000000 ffff0000080d0f40 0000ffff7b2584c0
[ 4294.839432] fc40: 0000ffffda3b0690 0000000000000140 0000000000000000 ffff803f6deaf108
[ 4294.847247] fc60: ffff00000815e680 ffff803f6dfa7000 ffff000008165b34 0000000000000000
[ 4294.855062] fc80: 00000000000000a7 ffff000008902000 ffff803f6e7bb200 ffff803f5c07fce0
[ 4294.862877] fca0: ffff0000081318f0 ffff803f5c07fce0 ffff0000081318f4 0000000020000145
[ 4294.870691] fcc0: ffff803f5c07fce0 ffff0000081318f0 0001000000000000 00000000000000a7
[ 4294.878506] [<ffff0000080827f4>] el1_irq+0xb4/0x128
[ 4294.883377] [<ffff0000081318f4>] generic_exec_single+0xe4/0x120
[ 4294.889289] [<ffff000008131a3c>] smp_call_function_single+0x10c/0x164
[ 4294.895719] [<ffff00000815ee94>] task_function_call+0x40/0x5c
[ 4294.901456] [<ffff00000815ef38>] event_function_call+0x88/0xf0
[ 4294.907282] [<ffff00000815f058>] _perf_event_enable+0x54/0x80
[ 4294.913018] [<ffff00000815ea2c>] perf_event_for_each_child+0x38/0x98
[ 4294.919359] [<ffff000008166a48>] perf_event_task_enable+0x58/0xa0
[ 4294.925443] [<ffff0000080d11e0>] SyS_prctl+0x2a0/0x3fc
[ 4294.930573] [<ffff000008082f8c>] __sys_trace_return+0x0/0x4
10-175-112-211:~ #
10-175-112-211:~ # [ 4321.341680] NMI watchdog: BUG: soft lockup - CPU#14 stuck for 22s! [perf_fuzzer:31306]
[ 4321.349583] Modules linked in:
[ 4321.352641]
[ 4321.354146] CPU: 14 PID: 31306 Comm: perf_fuzzer Not tainted 4.10.0-rc1-ga1d2732-dirty #7
[ 4321.362306] Hardware name: Huawei Taishan 2180 /BC11SPCC, BIOS 1.31 06/23/2016
[ 4321.369515] task: ffff803f6e7bb200 task.stack: ffff803f5c07c000
[ 4321.375428] PC is at __do_softirq+0xc0/0x240
[ 4321.379698] LR is at irq_exit+0xd0/0x118
[ 4321.383618] pc : [<ffff0000080c29b0>] lr : [<ffff0000080c2e40>] pstate: 40000145
[ 4321.390999] sp : ffff803ffffb2f50
[ 4321.394314] x29: ffff803ffffb2f50 x28: ffff803f6e7bb200
[ 4321.399619] x27: 0000000000000282 x26: ffff803ffffb3090
[ 4321.404922] x25: ffff000008ba1000 x24: 000000000000001b
[ 4321.410229] x23: ffff000008bc5728 x22: ffff000008d9b000
[ 4321.415532] x21: ffff000008d9fb08 x20: 0000000000000000
[ 4321.420836] x19: ffff000008d9b000 x18: 0000ffffda3b0690
[ 4321.426139] x17: 000000000000e654 x16: ffff0000080d0f40
[ 4321.431444] x15: 0000803ff7214000 x14: ffff000008ba6000
[ 4321.436747] x13: 00000003e8000000 x12: 0000000000000018
[ 4321.442053] x11: 0000ffffda3b0880 x10: 0000000000000002
[ 4321.447356] x9 : 0000000000000002 x8 : 0000000000000000
[ 4321.452659] x7 : 0000000001572fe1 x6 : 001df84284000000
[ 4321.457965] x5 : 0000000000000020 x4 : 000000000ccccccd
[ 4321.463270] x3 : 0000803ff7214000 x2 : ffff000008ed3300
[ 4321.468577] x1 : ffff000008ed3300 x0 : 0000000000000700
[ 4321.473882]
Message from syslogd@localhost at Feb 25 11:07:22 ...
kernel:[ 4321.341680] NMI watchdog: BUG: soft lockup - CPU#14 stuck for 22s! [perf_fuzzer:31306]
10-175-112-211:~ #
10-175-112-211:~ # [ 4349.341680] NMI watchdog: BUG: soft lockup - CPU#14 stuck for 22s! [perf_fuzzer:31306]
[ 4349.349580] Modules linked in:
[ 4349.352637]
[ 4349.354138] CPU: 14 PID: 31306 Comm: perf_fuzzer Tainted: G L 4.10.0-rc1-ga1d2732-dirty #7
[ 4349.363506] Hardware name: Huawei Taishan 2180 /BC11SPCC, BIOS 1.31 06/23/2016
[ 4349.370714] task: ffff803f6e7bb200 task.stack: ffff803f5c07c000
[ 4349.376624] PC is at __do_softirq+0xc0/0x240
[ 4349.380893] LR is at irq_exit+0xd0/0x118
[ 4349.384815] pc : [<ffff0000080c29b0>] lr : [<ffff0000080c2e40>] pstate: 40000145
[ 4349.392195] sp : ffff803ffffb2f50
[ 4349.395513] x29: ffff803ffffb2f50 x28: ffff803f6e7bb200
[ 4349.400817] x27: 0000000000000282 x26: ffff803ffffb3090
[ 4349.406121] x25: ffff000008ba1000 x24: 000000000000001b
[ 4349.411424] x23: ffff000008bc5728 x22: ffff000008d9b000
[ 4349.416727] x21: ffff000008d9fb08 x20: 0000000000000000
[ 4349.422032] x19: ffff000008d9b000 x18: 0000ffffda3b0690
[ 4349.427337] x17: 000000000000e654 x16: ffff0000080d0f40
[ 4349.432640] x15: 0000803ff7214000 x14: ffff000008ba6000
[ 4349.437944] x13: 00000003e8000000 x12: 0000000000000018
[ 4349.443248] x11: 0000ffffda3b0880 x10: 0000000000000002
[ 4349.448552] x9 : 0000000000000002 x8 : 0000000000000000
[ 4349.453856] x7 : 0000000001572fe1 x6 : 001df84284000000
[ 4349.459162] x5 : 0000000000000020 x4 : 000000000ccccccd
[ 4349.464465] x3 : 0000803ff7214000 x2 : ffff000008ed3300
[ 4349.469769] x1 : ffff000008ed3300 x0 : 0000000000000700
[ 4349.475072]
------------------------------------
part of objdump code:
ffff0000080c29a8: b820683f str wzr, [x1,x0]
return flags;
}
static inline void arch_local_irq_enable(void)
{
asm volatile(
ffff0000080c29ac: d50342ff msr daifclr, #0x2
local_irq_enable();
h = softirq_vec;
ffff0000080c29b0: 90006920 adrp x0, ffff000008de6000 <boot_args>
while ((softirq_bit = ffs(pending))) {
unsigned int vec_nr;
int prev_count;
h += softirq_bit - 1;
ffff0000080c29b4: 928000f4 mov x20, #0xfffffffffffffff8 // #-8
/* Reset the pending bitmask before enabling irqs */
set_softirq_pending(0);
local_irq_enable();
h = softirq_vec;
ffff0000080c29b8: 9106001c add x28, x0, #0x180
unsigned int vec_nr;
int prev_count;
h += softirq_bit - 1;
-----------------------------------------
On 2017/2/24 17:15, tip-bot for Tan Xiaojun wrote:
> Commit-ID: 1572e45a924f254d9570093abde46430c3172e3d
> Gitweb: http://git.kernel.org/tip/1572e45a924f254d9570093abde46430c3172e3d
> Author: Tan Xiaojun <tanxiaojun@huawei.com>
> AuthorDate: Thu, 23 Feb 2017 14:04:39 +0800
> Committer: Ingo Molnar <mingo@kernel.org>
> CommitDate: Fri, 24 Feb 2017 08:56:33 +0100
>
> perf/core: Fix the perf_cpu_time_max_percent check
>
> Use "proc_dointvec_minmax" instead of "proc_dointvec" to check the input
> value from user-space.
>
> If not, we can set a big value and some vars will overflow like
> "sysctl_perf_event_sample_rate" which will cause a lot of unexpected
> problems.
>
> Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: <acme@kernel.org>
> Cc: <alexander.shishkin@linux.intel.com>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Jiri Olsa <jolsa@redhat.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Stephane Eranian <eranian@google.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Vince Weaver <vincent.weaver@maine.edu>
> Link: http://lkml.kernel.org/r/1487829879-56237-1-git-send-email-tanxiaojun@huawei.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> ---
> kernel/events/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index d4e3f8d..c1c1cdf 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -455,7 +455,7 @@ int perf_cpu_time_max_percent_handler(struct ctl_table *table, int write,
> void __user *buffer, size_t *lenp,
> loff_t *ppos)
> {
> - int ret = proc_dointvec(table, write, buffer, lenp, ppos);
> + int ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
>
> if (ret || !write)
> return ret;
>
> .
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [tip:perf/urgent] perf/core: Fix the perf_cpu_time_max_percent check
2017-02-25 8:10 ` Tan Xiaojun
@ 2017-02-25 9:51 ` Peter Zijlstra
2017-02-27 0:36 ` Tan Xiaojun
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Peter Zijlstra @ 2017-02-25 9:51 UTC (permalink / raw)
To: Tan Xiaojun
Cc: jolsa, alexander.shishkin, eranian, hpa, mingo, linux-kernel,
acme, acme, vincent.weaver, tglx, torvalds, linux-tip-commits,
linux-arm-kernel
On Sat, Feb 25, 2017 at 04:10:37PM +0800, Tan Xiaojun wrote:
> Recently I was using perf_fuzzer for testing in Hisilicon
> D03/D05(arm64, linux-4.10-rc1).
>
> As we know perf_fuzzer will write a random value to procfs interface
> of perf event(like sysctl_perf_cpu_time_max_percent). The value may be
> 0 or 100, and I get logs like below:
>
> ----------------------------------
> [ 4046.358811] perf: Dynamic interrupt throttling disabled, can hang your system!
> ----------------------------------
>
> Most of the time, there is no problem, and the perf_fuzzer test can
> end without any warings or errors. But there is a small probability
> that triggers the RCU and watchdog (The log is attached at the end).
> It hungs after local_irq_enable() in __do_softirq.
>
> I think this is due to the dynamic interrupt throttling disabled and
> too many hardware interruptions come. So I limit the
> sysctl_perf_cpu_time_max_percent can only be set 1 to 99 in the kernel
> codes. I test more than 20 times in D03, and there are no errors or
> warnings in the test.
>
> So I want to ask:
>
> 1)Is it a problem or not? (It has already given you a warning.)
>
> 2)If it is, where we will fix it more appropriate, perf_fuzzer(not set
> 0 or 100) or kernel(limit 1 to 99), or maybe it is the bug of
> hardware(too many hardware interruptions)?
I think the best would be if the fuzzer would not set 0,100, those are
clearly 'unsafe' settings and you pretty much get to keep the pieces.
I would like to preserve these settings for people that 'know' what
they're doing and are willing to take the risk, but clearly, when you
take the guard-rails off, things can come apart.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [tip:perf/urgent] perf/core: Fix the perf_cpu_time_max_percent check
2017-02-25 9:51 ` Peter Zijlstra
@ 2017-02-27 0:36 ` Tan Xiaojun
2017-03-13 18:35 ` Vince Weaver
2017-04-15 7:58 ` [BUG arm64] OOPS when using /proc/kcore to disassemble the kernel symbols in "perf top" Tan Xiaojun
2 siblings, 0 replies; 8+ messages in thread
From: Tan Xiaojun @ 2017-02-27 0:36 UTC (permalink / raw)
To: Peter Zijlstra
Cc: jolsa, alexander.shishkin, eranian, hpa, mingo, linux-kernel,
acme, acme, vincent.weaver, tglx, torvalds, linux-tip-commits,
linux-arm-kernel
On 2017/2/25 17:51, Peter Zijlstra wrote:
> On Sat, Feb 25, 2017 at 04:10:37PM +0800, Tan Xiaojun wrote:
>
>> Recently I was using perf_fuzzer for testing in Hisilicon
>> D03/D05(arm64, linux-4.10-rc1).
>>
>> As we know perf_fuzzer will write a random value to procfs interface
>> of perf event(like sysctl_perf_cpu_time_max_percent). The value may be
>> 0 or 100, and I get logs like below:
>>
>> ----------------------------------
>> [ 4046.358811] perf: Dynamic interrupt throttling disabled, can hang your system!
>> ----------------------------------
>>
>> Most of the time, there is no problem, and the perf_fuzzer test can
>> end without any warings or errors. But there is a small probability
>> that triggers the RCU and watchdog (The log is attached at the end).
>> It hungs after local_irq_enable() in __do_softirq.
>>
>> I think this is due to the dynamic interrupt throttling disabled and
>> too many hardware interruptions come. So I limit the
>> sysctl_perf_cpu_time_max_percent can only be set 1 to 99 in the kernel
>> codes. I test more than 20 times in D03, and there are no errors or
>> warnings in the test.
>>
>> So I want to ask:
>>
>> 1)Is it a problem or not? (It has already given you a warning.)
>>
>> 2)If it is, where we will fix it more appropriate, perf_fuzzer(not set
>> 0 or 100) or kernel(limit 1 to 99), or maybe it is the bug of
>> hardware(too many hardware interruptions)?
>
> I think the best would be if the fuzzer would not set 0,100, those are
> clearly 'unsafe' settings and you pretty much get to keep the pieces.
>
> I would like to preserve these settings for people that 'know' what
> they're doing and are willing to take the risk, but clearly, when you
> take the guard-rails off, things can come apart.
>
OK. It makes sense, I agree.
Thank you for your answer.
Xiaojun.
> .
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [tip:perf/urgent] perf/core: Fix the perf_cpu_time_max_percent check
2017-02-25 9:51 ` Peter Zijlstra
2017-02-27 0:36 ` Tan Xiaojun
@ 2017-03-13 18:35 ` Vince Weaver
2017-03-14 1:52 ` Tan Xiaojun
2017-04-15 7:58 ` [BUG arm64] OOPS when using /proc/kcore to disassemble the kernel symbols in "perf top" Tan Xiaojun
2 siblings, 1 reply; 8+ messages in thread
From: Vince Weaver @ 2017-03-13 18:35 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Tan Xiaojun, jolsa, alexander.shishkin, eranian, mingo, linux-kernel
On Sat, 25 Feb 2017, Peter Zijlstra wrote:
> On Sat, Feb 25, 2017 at 04:10:37PM +0800, Tan Xiaojun wrote:
>
> > 2)If it is, where we will fix it more appropriate, perf_fuzzer(not set
> > 0 or 100) or kernel(limit 1 to 99), or maybe it is the bug of
> > hardware(too many hardware interruptions)?
>
> I think the best would be if the fuzzer would not set 0,100, those are
> clearly 'unsafe' settings and you pretty much get to keep the pieces.
>
> I would like to preserve these settings for people that 'know' what
> they're doing and are willing to take the risk, but clearly, when you
> take the guard-rails off, things can come apart.
sorry for the delay responding, these e-mails ended up in the spam folder
somehow.
I could add a new "avoid stupid things as root" flag for the perf_fuzzer.
Besides this issue, are there other known things to skip?
Generally running a fuzzer as root can be a bad idea which is why I don't
test that use case very often.
I think there were other issues in the past, like certain ftrace
combinations being known to lock the system.
Vince
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [tip:perf/urgent] perf/core: Fix the perf_cpu_time_max_percent check
2017-03-13 18:35 ` Vince Weaver
@ 2017-03-14 1:52 ` Tan Xiaojun
0 siblings, 0 replies; 8+ messages in thread
From: Tan Xiaojun @ 2017-03-14 1:52 UTC (permalink / raw)
To: Vince Weaver, Peter Zijlstra
Cc: jolsa, alexander.shishkin, eranian, mingo, linux-kernel
On 2017/3/14 2:35, Vince Weaver wrote:
> On Sat, 25 Feb 2017, Peter Zijlstra wrote:
>
>> On Sat, Feb 25, 2017 at 04:10:37PM +0800, Tan Xiaojun wrote:
>>
>>> 2)If it is, where we will fix it more appropriate, perf_fuzzer(not set
>>> 0 or 100) or kernel(limit 1 to 99), or maybe it is the bug of
>>> hardware(too many hardware interruptions)?
>>
>> I think the best would be if the fuzzer would not set 0,100, those are
>> clearly 'unsafe' settings and you pretty much get to keep the pieces.
>>
>> I would like to preserve these settings for people that 'know' what
>> they're doing and are willing to take the risk, but clearly, when you
>> take the guard-rails off, things can come apart.
>
> sorry for the delay responding, these e-mails ended up in the spam folder
> somehow.
>
> I could add a new "avoid stupid things as root" flag for the perf_fuzzer.
>
> Besides this issue, are there other known things to skip?
>
> Generally running a fuzzer as root can be a bad idea which is why I don't
> test that use case very often.
> I think there were other issues in the past, like certain ftrace
> combinations being known to lock the system.
>
> Vince
>
It would be better if you could add such a flag to the perf_fuzzer. And I
have not found any other problems yet.
By the way. Use Non-root user to test is OK, and they do not have permission
to configure these parameters.
Thank you for your reply.
Xiaojun.
> .
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [BUG arm64] OOPS when using /proc/kcore to disassemble the kernel symbols in "perf top"
2017-02-25 9:51 ` Peter Zijlstra
2017-02-27 0:36 ` Tan Xiaojun
2017-03-13 18:35 ` Vince Weaver
@ 2017-04-15 7:58 ` Tan Xiaojun
2 siblings, 0 replies; 8+ messages in thread
From: Tan Xiaojun @ 2017-04-15 7:58 UTC (permalink / raw)
To: Peter Zijlstra
Cc: jolsa, alexander.shishkin, eranian, hpa, mingo, linux-kernel,
acme, acme, tglx, torvalds, linux-tip-commits, linux-arm-kernel,
Ding Tianhong
[-- Attachment #1: Type: text/plain, Size: 9223 bytes --]
Hi,
My test server is Hisilicon D03/D05 (arm64).
Kernel source code is 4.11-rc6 (up to date) and config (as an attachment in the end) is generated by defconfig.
When I do "perf top" and annotate a random kernel symbol (like vsnprintf or others), the system report an OOPS below:
(The probability of occurrence is very high, almost every time.)
$ perf top
Annotate vsnprintf ---- choose it
Zoom into perf(7066) thread
Zoom into the Kernel DSO
Browse map details
Run scripts for samples of thread [perf]
Run scripts for samples of symbol [vsnprintf]
Run scripts for all samples
Exit
log:
Apr 17 05:03:59 EulerOS kernel: [ 339.913498] Unable to handle kernel paging request at virtual address ffffdb16aa14028c
Apr 17 05:03:59 EulerOS kernel: [ 339.913502] pgd = ffff803f70b29000
Apr 17 05:03:59 EulerOS kernel: [ 339.913506] [ffffdb16aa14028c] *pgd=0000000000000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913511] Internal error: Oops: 96000004 [#1] PREEMPT SMP
Apr 17 05:03:59 EulerOS kernel: [ 339.913514] Modules linked in:
Apr 17 05:03:59 EulerOS kernel: [ 339.913520] CPU: 6 PID: 9703 Comm: perf Not tainted 4.11.0-rc6-00029-gb9b3322 #3
Apr 17 05:03:59 EulerOS kernel: [ 339.913523] Hardware name: Huawei Taishan 2180 /BC11SPCC, BIOS 1.31 06/23/2016
Apr 17 05:03:59 EulerOS kernel: [ 339.913526] task: ffff803f6ff99a00 task.stack: ffff803f4c104000
Apr 17 05:03:59 EulerOS kernel: [ 339.913531] PC is at __memcpy+0x38/0x180
Apr 17 05:03:59 EulerOS kernel: [ 339.913535] LR is at vread+0x148/0x284
Apr 17 05:03:59 EulerOS kernel: [ 339.913538] pc : [<ffff0000083926b8>] lr : [<ffff0000081ba2a0>] pstate: 00000145
Apr 17 05:03:59 EulerOS kernel: [ 339.913540] sp : ffff803f4c107c70
Apr 17 05:03:59 EulerOS kernel: [ 339.913542] x29: ffff803f4c107c70 x28: ffff803f5ef73000
Apr 17 05:03:59 EulerOS kernel: [ 339.913548] x27: 000000000000032c x26: ffff803f6ff99a00
Apr 17 05:03:59 EulerOS kernel: [ 339.913552] x25: ffff00000839d28c x24: ffff803f7f801380
Apr 17 05:03:59 EulerOS kernel: [ 339.913557] x23: 000000000000032c x22: ffff803f5ef73000
Apr 17 05:03:59 EulerOS kernel: [ 339.913561] x21: 000000000000028c x20: ffff00000839d28c
Apr 17 05:03:59 EulerOS kernel: [ 339.913565] x19: 000000000000032c x18: 0000ffffaa6cc2d0
Apr 17 05:03:59 EulerOS kernel: [ 339.913569] x17: 0000ffffab9dc350 x16: ffff0000081f5f04
Apr 17 05:03:59 EulerOS kernel: [ 339.913573] x15: 0000317ba8000000 x14: 001c19d1d0000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913577] x13: 00000003e8000000 x12: 0000000000000006
Apr 17 05:03:59 EulerOS kernel: [ 339.913581] x11: 0000000000000007 x10: 0000000000000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913586] x9 : 0000000000000000 x8 : ffff000008e6d3d8
Apr 17 05:03:59 EulerOS kernel: [ 339.913590] x7 : 00005b16aa140000 x6 : ffff803f5ef73000
Apr 17 05:03:59 EulerOS kernel: [ 339.913594] x5 : 0000000000000d74 x4 : 0000000000000004
Apr 17 05:03:59 EulerOS kernel: [ 339.913598] x3 : 0000000000000000 x2 : 0000000000000328
Apr 17 05:03:59 EulerOS kernel: [ 339.913602] x1 : ffffdb16aa14028c x0 : ffff803f5ef73000
Apr 17 05:03:59 EulerOS kernel: [ 339.913606]
Apr 17 05:03:59 EulerOS kernel: [ 339.913609] Process perf (pid: 9703, stack limit = 0xffff803f4c104000)
Apr 17 05:03:59 EulerOS kernel: [ 339.913612] Stack: (0xffff803f4c107c70 to 0xffff803f4c108000)
Apr 17 05:03:59 EulerOS kernel: [ 339.913615] 7c60: ffff803f4c107d00 ffff000008267a18
Apr 17 05:03:59 EulerOS kernel: [ 339.913619] 7c80: 000000000000032c 0000000036dd9c10 ffff000008f75160 ffff803f4c107eb8
Apr 17 05:03:59 EulerOS kernel: [ 339.913622] 7ca0: 0000000000000000 ffff803f6ff99a00 ffff803f5ef73000 ffff000008e6d3d8
Apr 17 05:03:59 EulerOS kernel: [ 339.913625] 7cc0: ffff00000839d28c 000000000000032c 0000000000000024 ffff803f5ef73000
Apr 17 05:03:59 EulerOS kernel: [ 339.913629] 7ce0: 000000000000032c 000000000000032c ffff803f6ff99a00 ffff000008e684a0
Apr 17 05:03:59 EulerOS kernel: [ 339.913632] 7d00: ffff803f4c107d90 ffff000008259d00 ffff803f720c3d00 fffffffffffffffb
Apr 17 05:03:59 EulerOS kernel: [ 339.913635] 7d20: 0000000036dd9c10 ffff803f4c107eb8 0000000080000000 0000000000000015
Apr 17 05:03:59 EulerOS kernel: [ 339.913638] 7d40: 0000000000000124 000000000000003f ffff000008942000 ffff803f6ff99a00
Apr 17 05:03:59 EulerOS kernel: [ 339.913641] 7d60: ffff803f6ff08310 ffff803f6ff99a00 ffff803f6ff99a00 ffff803f6ff99a00
Apr 17 05:03:59 EulerOS kernel: [ 339.913644] 7d80: 0000000d00000124 0000000000002000 ffff803f4c107db0 ffff0000081f3810
Apr 17 05:03:59 EulerOS kernel: [ 339.913647] 7da0: ffff803f6ff08300 ffff803f4c107eb8 ffff803f4c107e30 ffff0000081f4ab0
Apr 17 05:03:59 EulerOS kernel: [ 339.913650] 7dc0: 000000000000032c ffff803f6ff08300 0000000000000000 0000000000000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913653] 7de0: ffff803f4c107e10 ffff0000081f49ac ffff803f6ff08300 0000000000000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913656] 7e00: 0000000036dd9c10 ffff803f4c107eb8 ffff803f4c107e30 ffff0000081f4a8c
Apr 17 05:03:59 EulerOS kernel: [ 339.913659] 7e20: 000000000000032c ffff803f6ff08300 ffff803f4c107e70 ffff0000081f5f48
Apr 17 05:03:59 EulerOS kernel: [ 339.913662] 7e40: ffff803f6ff08303 ffff803f6ff08300 ffffffffffffffff 0000ffffab9dc37c
Apr 17 05:03:59 EulerOS kernel: [ 339.913664] 7e60: 0000000000000200 0000ffffab9dcbdc 0000000000000000 ffff000008082f8c
Apr 17 05:03:59 EulerOS kernel: [ 339.913667] 7e80: 0000000000000200 0000803ff70f9000 ffffffffffffffff ffff000008082f5c
Apr 17 05:03:59 EulerOS kernel: [ 339.913670] 7ea0: 0000000036dd9c10 000000000000032c ffffffffffffffff 000000000839f28c
Apr 17 05:03:59 EulerOS kernel: [ 339.913673] 7ec0: 000000000000002a 0000000036dd9c10 000000000000032c 0000ffffaa6d42c8
Apr 17 05:03:59 EulerOS kernel: [ 339.913676] 7ee0: 0000ffffaa6cc49c 0000ffffaa6d41c0 0000ffffaa6d48b0 0000000000000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913679] 7f00: 000000000000003f 0000000000000003 0000000000000020 0000000000000007
Apr 17 05:03:59 EulerOS kernel: [ 339.913682] 7f20: 0000000000000006 00000003e8000000 001c19d1d0000000 0000317ba8000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913685] 7f40: 0000000000000000 0000ffffab9dc350 0000ffffaa6cc2d0 0000000000622000
Apr 17 05:03:59 EulerOS kernel: [ 339.913688] 7f60: 0000000000001000 0000000036dd9c10 000000000000032c 00000000006f1038
Apr 17 05:03:59 EulerOS kernel: [ 339.913691] 7f80: 000000000000002b 000000000000002a 000000000839f28c 0000000000000001
Apr 17 05:03:59 EulerOS kernel: [ 339.913694] 7fa0: 0000ffffaa6d3990 0000ffffaa6cc4e0 0000ffffab9dc368 0000ffffaa6cc4a0
Apr 17 05:03:59 EulerOS kernel: [ 339.913697] 7fc0: 0000ffffab9dc37c 0000000080000000 000000000000002a 000000000000003f
Apr 17 05:03:59 EulerOS kernel: [ 339.913700] 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913702] Call trace:
Apr 17 05:03:59 EulerOS kernel: [ 339.913705] Exception stack(0xffff803f4c107aa0 to 0xffff803f4c107bd0)
Apr 17 05:03:59 EulerOS kernel: [ 339.913708] 7aa0: 000000000000032c 0001000000000000 ffff803f4c107c70 ffff0000083926b8
Apr 17 05:03:59 EulerOS kernel: [ 339.913712] 7ac0: 00000000014200ca 0000000000000000 ffff803f71b1ec38 0000000000000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913715] 7ae0: ffff803f6ff99a00 0000000036dda000 0000000000000000 0000000000000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913718] 7b00: 000000000000000c ffff000008f6c610 ffff803f4c107b60 ffff0000082c0ae0
Apr 17 05:03:59 EulerOS kernel: [ 339.913721] 7b20: ffff803f7047a030 ffff000008f76000 0000000000000000 ffff803f7200a800
Apr 17 05:03:59 EulerOS kernel: [ 339.913724] 7b40: ffff803f5ef73000 ffffdb16aa14028c 0000000000000328 0000000000000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913727] 7b60: 0000000000000004 0000000000000d74 ffff803f5ef73000 00005b16aa140000
Apr 17 05:03:59 EulerOS kernel: [ 339.913729] 7b80: ffff000008e6d3d8 0000000000000000 0000000000000000 0000000000000007
Apr 17 05:03:59 EulerOS kernel: [ 339.913732] 7ba0: 0000000000000006 00000003e8000000 001c19d1d0000000 0000317ba8000000
Apr 17 05:03:59 EulerOS kernel: [ 339.913735] 7bc0: ffff0000081f5f04 0000ffffab9dc350
Apr 17 05:03:59 EulerOS kernel: [ 339.913739] [<ffff0000083926b8>] __memcpy+0x38/0x180
Apr 17 05:03:59 EulerOS kernel: [ 339.913743] [<ffff000008267a18>] read_kcore+0x230/0x3b0
Apr 17 05:03:59 EulerOS kernel: [ 339.913747] [<ffff000008259d00>] proc_reg_read+0x64/0x90
Apr 17 05:03:59 EulerOS kernel: [ 339.913751] [<ffff0000081f3810>] __vfs_read+0x28/0x108
Apr 17 05:03:59 EulerOS kernel: [ 339.913754] [<ffff0000081f4ab0>] vfs_read+0x80/0x13c
Apr 17 05:03:59 EulerOS kernel: [ 339.913757] [<ffff0000081f5f48>] SyS_read+0x44/0xa0
Apr 17 05:03:59 EulerOS kernel: [ 339.913761] [<ffff000008082f8c>] __sys_trace_return+0x0/0x4
Apr 17 05:03:59 EulerOS kernel: [ 339.913765] Code: 36080064 78402423 780024c3 36100064 (b8404423)
Apr 17 05:03:59 EulerOS kernel: [ 339.913768] ---[ end trace 6710f03ffe50aedc ]---
Apr 17 05:03:59 EulerOS kernel: [ 339.913772] note: perf[9703] exited with preempt_count 2
Call relationship:
read_kcore -> vread -> aligned_vread -> memcpy -> __memcpy
Maybe you can give me some ideas.
Thanks a lot.
Xiaojun.
[-- Attachment #2: .config --]
[-- Type: application/xml, Size: 150271 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-04-15 8:08 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-23 6:04 [PATCH] perf/core: Fix to check perf_cpu_time_max_percent Tan Xiaojun
2017-02-24 9:15 ` [tip:perf/urgent] perf/core: Fix the perf_cpu_time_max_percent check tip-bot for Tan Xiaojun
2017-02-25 8:10 ` Tan Xiaojun
2017-02-25 9:51 ` Peter Zijlstra
2017-02-27 0:36 ` Tan Xiaojun
2017-03-13 18:35 ` Vince Weaver
2017-03-14 1:52 ` Tan Xiaojun
2017-04-15 7:58 ` [BUG arm64] OOPS when using /proc/kcore to disassemble the kernel symbols in "perf top" Tan Xiaojun
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).