From: Hou Tao <houtao1@huawei.com>
To: <aarcange@redhat.com>, <linux-kernel@vger.kernel.org>
Cc: <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>,
<dwmw@amazon.co.uk>, <ak@linux.intel.com>,
<dave.hansen@linux.intel.com>, <peterz@infradead.org>,
<qiuxishi@huawei.com>, <wangkefeng.wang@huawei.com>
Subject: [RH72 Spectre] ibpb_enabled = 1 leads to hard LOCKUP under x86_64 host machine
Date: Sat, 20 Jan 2018 17:00:33 +0800 [thread overview]
Message-ID: <12e55119-4f5b-da63-2b1c-14fb70243b21@huawei.com> (raw)
Hi all,
We are testing the patches for Spectre and Meltdown under OS derived from RH7.2,
and hit by a hard LOCKUP panic under a x86_64 host environment.
The hard LOCKUP can be reproduced, and it will gone if we disable ibpb by
writing 0 to ibpb_enabled file, and it will appear again when we enable ibpb
( writing 1 or 2).
The workload running on the host is just starting two hundreds security
containers sequentially, then stopping them and repeating. The security
container is implemented by using docker and kvm, so there will be many
"docker-containerd-shim" and "qemu-system-x86_64uvm" processes. The reproduction
of the hard LOCKUP problem can be accelerated by running the following command
("hackbench" comes from ltp project):
while true; do ./hackbench 100 process 1000; done
We have saved vmcore files for the hard LOCKUPs by using kdump. The hard LOCKUPs
are triggerd by different processes and on different Linux kernel stack. We have
analyzed one hard LOCKUP, it is caused by wake_up_new_task() when it tried to
get rq->lock by invoking __task_rq_lock(). The value of the lock is 422320416
(head = 6432, tail = 6444), and we have found the five processes which are
waiting on the lock, but we can not find the process which had taken it.
We guess maybe something is wrong with the CPU scheduler, because the RSP
register of process runv which is waiting for rq->lock is incorrect. The RSP
pointers the stack of swapper/57 and runv is also running on CPU 57 (more
details in the end of the mail). The same phenomenon exists on others hardLOCKs.
So has anyone encountered a similar problem before, and any suggestions
and directions for the hard LOCKUP problems ?
Thanks,
Tao
---
The following lines are output from one instance of the hard LOCKUP panics:
* output from crash which complain about the unexpected RSP register:
crash: inconsistent active task indications for CPU 57:
runqueue: ffff882eac72e780 "runv" (default)
current_task: ffff882f768e1700 "swapper/57"
crash> runq -m -c 57
CPU 57: [0 00:00:00.000] PID: 8173 TASK: ffff882eac72e780 COMMAND: "runv"
crash> bt 8173
PID: 8173 TASK: ffff882eac72e780 CPU: 57 COMMAND: "runv"
#0 [ffff885fbe145e00] stop_this_cpu at ffffffff8101f66d
#1 [ffff885fbe145e10] kbox_rlock_stop_other_cpus_call at ffffffffa031e649
#2 [ffff885fbe145e50] smp_nmi_call_function_handler at ffffffff81047dd6
#3 [ffff885fbe145e68] nmi_handle at ffffffff8164fc09
#4 [ffff885fbe145eb0] do_nmi at ffffffff8164fd84
#5 [ffff885fbe145ef0] end_repeat_nmi at ffffffff8164eff9
[exception RIP: _raw_spin_lock+48]
RIP: ffffffff8164dc50 RSP: ffff882f768f3b18 RFLAGS: 00000002
RAX: 0000000000000a58 RBX: ffff882f76f1d080 RCX: 0000000000001920
RDX: 0000000000001922 RSI: 0000000000001922 RDI: ffff885fbe159580
RBP: ffff882f768f3b18 R8: 0000000000000012 R9: 0000000000000001
R10: 0000000000000400 R11: 0000000000000000 R12: ffff882f76f1d884
R13: 0000000000000046 R14: ffff885fbe159580 R15: 0000000000000039
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
--- <NMI exception stack> ---
#6 [ffff882f768f3b18] _raw_spin_lock at ffffffff8164dc50
bt: cannot transition from exception stack to current process stack:
exception stack pointer: ffff885fbe145e00
process stack pointer: ffff882f768f3b18
current stack base: ffff882f34e38000
* kernel panic message when hard LOCKUP occurs
[ 4396.807556] Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 55
[ 4396.807561] CPU: 55 PID: 8267 Comm: docker Tainted: G O ---- ------- 3.10.0-327.59.59.46.x86_64 #1
[ 4396.807563] Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 1.57 08/11/2015
[ 4396.807564] Call Trace:
[ 4396.807571] <NMI> [<ffffffff81646140>] dump_stack+0x19/0x1b
[ 4396.807575] [<ffffffff8163f792>] panic+0xd8/0x214
[ 4396.807582] [<ffffffff811228b1>] watchdog_overflow_callback+0xd1/0xe0
[ 4396.807589] [<ffffffff81166161>] __perf_event_overflow+0xa1/0x250
[ 4396.807595] [<ffffffff81166c34>] perf_event_overflow+0x14/0x20
[ 4396.807600] [<ffffffff810339b8>] intel_pmu_handle_irq+0x1e8/0x470
[ 4396.807610] [<ffffffff812ffc11>] ? ioremap_page_range+0x241/0x320
[ 4396.807617] [<ffffffff813a1044>] ? ghes_copy_tofrom_phys+0x124/0x210
[ 4396.807621] [<ffffffff813a11d0>] ? ghes_read_estatus+0xa0/0x190
[ 4396.807626] [<ffffffff8165058b>] perf_event_nmi_handler+0x2b/0x50
[ 4396.807629] [<ffffffff8164fc09>] nmi_handle.isra.0+0x69/0xb0
[ 4396.807633] [<ffffffff8164fd84>] do_nmi+0x134/0x410
[ 4396.807637] [<ffffffff8164eff9>] end_repeat_nmi+0x1e/0x7e
[ 4396.807643] [<ffffffff8164dc5a>] ? _raw_spin_lock+0x3a/0x50
[ 4396.807648] [<ffffffff8164dc5a>] ? _raw_spin_lock+0x3a/0x50
[ 4396.807653] [<ffffffff8164dc5a>] ? _raw_spin_lock+0x3a/0x50
[ 4396.807658] <<EOE>> [<ffffffff810bd33c>] wake_up_new_task+0x9c/0x170
[ 4396.807662] [<ffffffff8107dfbb>] do_fork+0x13b/0x320
[ 4396.807667] [<ffffffff8107e226>] SyS_clone+0x16/0x20
[ 4396.807672] [<ffffffff816577f4>] stub_clone+0x44/0x70
[ 4396.807676] [<ffffffff8165743d>] ? system_call_fastpath+0x16/0x1b
* cpu info for the first CPU (72 CPUs in total)
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
stepping : 2
microcode : 0x3b
cpu MHz : 2300.000
cache size : 46080 KB
physical id : 0
siblings : 36
core id : 0
cpu cores : 18
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 15
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm arat epb invpcid_single pln pts dtherm spec_ctrl ibpb_support tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc
bogomips : 4589.42
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
next reply other threads:[~2018-01-20 9:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-20 9:00 Hou Tao [this message]
2018-01-20 9:03 ` David Woodhouse
2018-01-20 13:56 ` Van De Ven, Arjan
2018-01-20 15:22 ` Andrea Arcangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12e55119-4f5b-da63-2b1c-14fb70243b21@huawei.com \
--to=houtao1@huawei.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw@amazon.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qiuxishi@huawei.com \
--cc=tglx@linutronix.de \
--cc=wangkefeng.wang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®