10:25 p.m.
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://github.com/0day-ci/linux
Borislav-Petkov/x86-Move-away-from-dev-cpu-msr/20160615-180354
commit 5ac0c41bf307ad74185284004062d85a21ecb82b
Author: Borislav Petkov <bp(a)alien8.de>
AuthorDate: Wed Jun 15 12:00:29 2016 +0200
Commit: 0day robot <fengguang.wu(a)intel.com>
CommitDate: Wed Jun 15 18:04:00 2016 +0800
x86: Move away from /dev/cpu/*/msr
Hi people,
so we've been talking about this for a long time now - how loading
msr.ko is not a good thing and how userspace shouldn't poke at random
MSRs.
So my intention is to move away users in tools/ which did write to MSRs
through the char dev and replace it with proper sysfs et al interfaces.
Once that's done, we can start tainting the kernel when writing to MSRs
from that device or even forbid it completely at some point.
We'll see.
Anyway, here's a first attempt, please scream if something's not right.
Functionality-wise, it should be equivalent as I'm exporting the
pref_hint of the IA32_ENERGY_PERF_BIAS in sysfs and it lands under
/sys/devices/system/cpu/cpu?/energy_policy_pref_hint
where anything with sufficient perms can read/write it.
Comments are, as always, appreciated.
+-----------------------------------------------------------+------------+------------+------------+
| | 0a26309f44 | 5ac0c41bf3 |
d2cf7f5a55 |
+-----------------------------------------------------------+------------+------------+------------+
| boot_successes | 62 | 0 | 0
|
| boot_failures | 3 | 26 | 13
|
| BUG:unable_to_handle_kernel | 2 | 1 |
|
| Oops | 3 | 1 |
|
| EIP_is_at_perf_prepare_sample | 3 | 1 |
|
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1 | |
|
| backtrace:iterate_dir | 2 | |
|
| backtrace:SyS_getdents64 | 2 | |
|
| Kernel_panic-not_syncing:Fatal_exception | 2 | 1 |
|
| WARNING:at_arch/x86/mm/extable.c:#ex_handler_rdmsr_unsafe | 0 | 26 | 13
|
| WARNING:at_arch/x86/mm/extable.c:#ex_handler_wrmsr_unsafe | 0 | 26 | 13
|
| backtrace:error_code | 0 | 26 | 13
|
| backtrace:init_intel_energy_perf | 0 | 26 | 13
|
| backtrace:init_intel | 0 | 26 | 13
|
+-----------------------------------------------------------+------------+------------+------------+
[ 0.556833] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.559888] ------------[ cut here ]------------
[ 0.559888] ------------[ cut here ]------------
[ 0.561405] WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50
ex_handler_rdmsr_unsafe+0x44/0x70
[ 0.561405] WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50
ex_handler_rdmsr_unsafe+0x44/0x70
[ 0.567649] unchecked MSR access error: RDMSR from 0x1b0
[ 0.567649] unchecked MSR access error: RDMSR from 0x1b0
[ 0.569396] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc3-00232-g5ac0c41 #254
[ 0.569396] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc3-00232-g5ac0c41 #254
[ 0.571860] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1
04/01/2014
[ 0.571860] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1
04/01/2014
[ 0.574583] 00200282
[ 0.574583] 00200282 00200282 00200282 81dffe50 81dffe50 812695a2 812695a2 81dffe94
81dffe94 81cda378 81cda378 81dffe80 81dffe80 8105a2de 8105a2de
[ 0.586073] 81cda348
[ 0.586073] 81cda348 81dffeb0 81dffeb0 00000000 00000000 81cda378 81cda378 00000032
00000032 81041d84 81041d84 00000032 00000032 81dfff04 81dfff04
[ 0.592643] 81041d40
[ 0.592643] 81041d40 0000000d 0000000d 81dffe9c 81dffe9c 8105a33b 8105a33b 00000009
00000009 00000000 00000000 81dffe94 81dffe94 81cda348 81cda348
[ 0.595200] Call Trace:
[ 0.595200] Call Trace:
[ 0.595956] [<812695a2>] dump_stack+0xa3/0xf1
[ 0.595956] [<812695a2>] dump_stack+0xa3/0xf1
[ 0.597286] [<8105a2de>] __warn+0xde/0x100
[ 0.597286] [<8105a2de>] __warn+0xde/0x100
[ 0.598536] [<81041d84>] ? ex_handler_rdmsr_unsafe+0x44/0x70
[ 0.598536] [<81041d84>] ? ex_handler_rdmsr_unsafe+0x44/0x70
[ 0.607349] [<81041d40>] ? ex_handler_ext+0x30/0x30
[ 0.607349] [<81041d40>] ? ex_handler_ext+0x30/0x30
[ 0.608880] [<8105a33b>] warn_slowpath_fmt+0x3b/0x40
[ 0.608880] [<8105a33b>] warn_slowpath_fmt+0x3b/0x40
[ 0.610469] [<81041d84>] ex_handler_rdmsr_unsafe+0x44/0x70
[ 0.610469] [<81041d84>] ex_handler_rdmsr_unsafe+0x44/0x70
[ 0.612153] [<81041ea8>] fixup_exception+0x28/0x40
[ 0.612153] [<81041ea8>] fixup_exception+0x28/0x40
[ 0.613642] [<810184e4>] do_general_protection+0x54/0x160
[ 0.613642] [<810184e4>] do_general_protection+0x54/0x160
[ 0.615674] [<8103da30>] ? kvm_setup_secondary_clock+0x30/0x30
[ 0.615674] [<8103da30>] ? kvm_setup_secondary_clock+0x30/0x30
[ 0.617463] [<81018490>] ? do_bounds+0x220/0x220
[ 0.617463] [<81018490>] ? do_bounds+0x220/0x220
[ 0.627326] [<819ec00f>] error_code+0x5f/0x70
[ 0.627326] [<819ec00f>] error_code+0x5f/0x70
[ 0.628639] [<8103da30>] ? kvm_setup_secondary_clock+0x30/0x30
[ 0.628639] [<8103da30>] ? kvm_setup_secondary_clock+0x30/0x30
[ 0.630410] [<81018490>] ? do_bounds+0x220/0x220
[ 0.630410] [<81018490>] ? do_bounds+0x220/0x220
[ 0.631848] [<8103da38>] ? native_read_msr+0x8/0x40
[ 0.631848] [<8103da38>] ? native_read_msr+0x8/0x40
[ 0.633412] [<8102ab53>] init_intel_energy_perf+0x33/0xb0
[ 0.633412] [<8102ab53>] init_intel_energy_perf+0x33/0xb0
[ 0.635016] [<8102b2fb>] init_intel+0x3db/0x440
[ 0.635016] [<8102b2fb>] init_intel+0x3db/0x440
[ 0.644516] [<810296f2>] identify_cpu+0x2f2/0x580
[ 0.644516] [<810296f2>] identify_cpu+0x2f2/0x580
[ 0.645999] [<810aaa52>] ? __raw_spin_lock_init+0x32/0x60
[ 0.645999] [<810aaa52>] ? __raw_spin_lock_init+0x32/0x60
[ 0.647673] [<81f1a507>] identify_boot_cpu+0xd/0x80
[ 0.647673] [<81f1a507>] identify_boot_cpu+0xd/0x80
[ 0.649151] [<81f1a5ac>] check_bugs+0x8/0x36
[ 0.649151] [<81f1a5ac>] check_bugs+0x8/0x36
[ 0.650475] [<81f0fbc7>] start_kernel+0x397/0x3ab
[ 0.650475] [<81f0fbc7>] start_kernel+0x397/0x3ab
[ 0.651979] [<81f0f2ba>] i386_start_kernel+0xa1/0xa5
[ 0.651979] [<81f0f2ba>] i386_start_kernel+0xa1/0xa5
[ 0.661389] ---[ end trace 30ec2dab0e40afe1 ]---
[ 0.661389] ---[ end trace 30ec2dab0e40afe1 ]---
git bisect start d2cf7f5a55daaccccc46ceec1da2bf67889916b8
5edb56491d4812c42175980759da53388e5d86f5 --
git bisect bad f16530cb909ab2270c1d89a0b4afd12b10229d03 # 19:31 0- 2 Merge
'linux-review/Suraj-Jitindar-Singh/kvm-ppc-book3s_hv-Change-vcore-element-runnable_threads-from-linked-list-to-array/20160615-172538'
into devel-catchup-201606151809
git bisect bad f46b8dd9ee264df81124101ae54866a5d62bccc5 # 19:35 0- 3 Merge
'cryptodev/master' into devel-catchup-201606151809
git bisect good 6afb4e72d08fc7000177459ddf2c4e91e3861ce8 # 19:40 22+ 0 Merge
'net-next/master' into devel-catchup-201606151809
git bisect good 77dac5782c0357a273f31cabcc65b8920f261fb4 # 19:47 22+ 1 Merge
'kdave/for-next' into devel-catchup-201606151809
git bisect bad 18b092a7594d2f58fb3558fac018e7e3a9d86b0d # 19:52 0- 22 Merge
'linux-review/Borislav-Petkov/x86-Move-away-from-dev-cpu-msr/20160615-180354' into
devel-catchup-201606151809
git bisect bad 5ac0c41bf307ad74185284004062d85a21ecb82b # 19:55 0- 22 x86:
Move away from /dev/cpu/*/msr
# first bad commit: [5ac0c41bf307ad74185284004062d85a21ecb82b] x86: Move away from
/dev/cpu/*/msr
git bisect good 0a26309f44946ab08439b87c5456df4f18614cd2 # 19:59 64+ 3 Merge
branch 'WIP.futex'
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect bad 5ac0c41bf307ad74185284004062d85a21ecb82b # 20:02 0- 3 x86:
Move away from /dev/cpu/*/msr
# extra tests on HEAD of linux-devel/devel-catchup-201606151809
git bisect bad d2cf7f5a55daaccccc46ceec1da2bf67889916b8 # 20:02 0- 13 0day
head guard for 'devel-catchup-201606151809'
# extra tests on tree/branch
linux-review/Borislav-Petkov/x86-Move-away-from-dev-cpu-msr/20160615-180354
git bisect bad 5ac0c41bf307ad74185284004062d85a21ecb82b # 20:10 0- 26 x86:
Move away from /dev/cpu/*/msr
# extra tests with first bad commit reverted
git bisect good adf0526f86dac4a966ee1cbf081645ce13934094 # 20:18 65+ 1 Revert
"x86: Move away from /dev/cpu/*/msr"
# extra tests on tree/branch linus/master
git bisect good db06d759d6cf903aeda8c107fd3abd366dd80200 # 20:21 63+ 1 Merge
branch 'for-4.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu
# extra tests on tree/branch linux-next/master
git bisect good 3a482945b1e6ab568e10347b7759d539c7a9f14f # 20:25 65+ 1 Add
linux-next specific files for 20160615
This script may reproduce the error.
----------------------------------------------------------------------------
#!/bin/bash
kernel=$1
initrd=quantal-core-i386.cgz
wget --no-clobber
https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
kvm=(
qemu-system-x86_64
-enable-kvm
-cpu kvm64
-kernel $kernel
-initrd $initrd
-m 300
-smp 2
-device e1000,netdev=net0
-netdev user,id=net0
-boot order=nc
-no-reboot
-watchdog i6300esb
-rtc base=localtime
-serial stdio
-display none
-monitor null
)
append=(
hung_task_panic=1
earlyprintk=ttyS0,115200
systemd.log_level=err
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
console=ttyS0,115200
console=tty0
vga=normal
root=/dev/ram0
rw
drbd.minor_count=8
)
"${kvm[@]}" --append "${append[*]}"
----------------------------------------------------------------------------
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/lkp Intel Corporation
12:25 a.m.
On Wed, Jun 15, 2016 at 08:25:57PM +0800, kernel test robot wrote:
[ 0.556833] Mountpoint-cache hash table entries: 1024 (order: 0,
4096 bytes)
[ 0.559888] ------------[ cut here ]------------
[ 0.559888] ------------[ cut here ]------------
[ 0.561405] WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50
ex_handler_rdmsr_unsafe+0x44/0x70
[ 0.561405] WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50
ex_handler_rdmsr_unsafe+0x44/0x70
[ 0.567649] unchecked MSR access error: RDMSR from 0x1b0
[ 0.567649] unchecked MSR access error: RDMSR from 0x1b0
Btw, Andy, this error message is completely useless - I
wanna know *where* the RDMSR in the code is, not point me at
ex_handler_rdmsr_unsafe().
IOW, I wanna convert the current thing into this:
[ 0.028003] unchecked MSR access error: RDMSR from 0x1b0 at rIP: 0xffffffff81026d9f
[ 0.030343] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.032003] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[ 0.036003] unchecked MSR access error: WRMSR to 0x1b0 (tried to write
0x0000000000000006) at rIP: 0xffffffff81026de1
i.e.,
---
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index 4bb53b89f3c5..2028a5ad3433 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -46,8 +46,8 @@ EXPORT_SYMBOL(ex_handler_ext);
bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
struct pt_regs *regs, int trapnr)
{
- WARN_ONCE(1, "unchecked MSR access error: RDMSR from 0x%x\n",
- (unsigned int)regs->cx);
+ pr_warn_once("unchecked MSR access error: RDMSR from 0x%x at rIP: 0x%lx\n",
+ (unsigned int)regs->cx, regs->ip);
/* Pretend that the read succeeded and returned 0. */
regs->ip = ex_fixup_addr(fixup);
@@ -60,9 +60,9 @@ EXPORT_SYMBOL(ex_handler_rdmsr_unsafe);
bool ex_handler_wrmsr_unsafe(const struct exception_table_entry *fixup,
struct pt_regs *regs, int trapnr)
{
- WARN_ONCE(1, "unchecked MSR access error: WRMSR to 0x%x (tried to write
0x%08x%08x)\n",
- (unsigned int)regs->cx,
- (unsigned int)regs->dx, (unsigned int)regs->ax);
+ pr_warn_once("unchecked MSR access error: WRMSR to 0x%x (tried to write 0x%08x%08x)
at rIP: 0x%lx\n",
+ (unsigned int)regs->cx, (unsigned int)regs->dx,
+ (unsigned int)regs->ax, regs->ip);
/* Pretend that the write succeeded. */
regs->ip = ex_fixup_addr(fixup);
---
Ok?
As to the error message, dear LKP friends, it happens because -cpu kvm64
on native Intel hands in CPUID bits of the host, i.e., if you do this in
the guest:
$ grep epb /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush mmx fxsr sse sse2 syscall nx lm constant_tsc nopl eagerfpu pni cx16 x2apic
hypervisor epb
^^^
you should have "epb" there too which is among those bits.
I can reproduce the same issue on an AMD host too by booting my guest
with
"-cpu kvm64,vendor=GenuineIntel"
Paolo, Eduardo, question: can we hide certain CPUID bits from the guest
when booting with -cpu kvm64?
In general, is there a way I can set or clear arbitrary CPUID bits so
that the guest sees what I want it to see?
And I don't mean the predefined CPUID flags which you toggle with "+" or
"-" followed by flag name. Because -cpu kvm64,-epb doesn't work.
Is there a way to make this work or should we hack it into qemu so that
we are able to do that? I.e., something like
-cpu=kvm64,cpuid=leaf6_ecx_bit3=0,...
or something smarter. But you get the idea...
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
12:51 a.m.
On Wed, Jun 15, 2016 at 04:25:32PM +0200, Borislav Petkov wrote:
[...]
As to the error message, dear LKP friends, it happens because -cpu kvm64
on native Intel hands in CPUID bits of the host, i.e., if you do this in
the guest:
$ grep epb /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush mmx fxsr sse sse2 syscall nx lm constant_tsc nopl eagerfpu pni cx16 x2apic
hypervisor epb
^^^
you should have "epb" there too which is among those bits.
It shouldn't. -cpu kvm64 should give exactly the same set of
CPUID bits on every host (unless you see "missing feature"
warnings. "-cpu kvm64,enforce" would be even more strict and
refuse to start if any feature is missing).
I can reproduce the same issue on an AMD host too by booting my guest
with
"-cpu kvm64,vendor=GenuineIntel"
Paolo, Eduardo, question: can we hide certain CPUID bits from the guest
when booting with -cpu kvm64?
In general, is there a way I can set or clear arbitrary CPUID bits so
that the guest sees what I want it to see?
And I don't mean the predefined CPUID flags which you toggle with "+" or
"-" followed by flag name. Because -cpu kvm64,-epb doesn't work.
If -cpu kvm64,-epb doesn't work, -cpu kvm64 is not supposed to
expose ebp to the guest in the first place.
CPUID[6].ECX, specifically, is hardcoded to 0 in QEMU.
Is there a way to make this work or should we hack it into qemu so that
we are able to do that? I.e., something like
-cpu=kvm64,cpuid=leaf6_ecx_bit3=0,...
or something smarter. But you get the idea...
We have that: it is "-feature" (or "feature=off"). Features that
can't be configured in the command-line should never appear to
the guest unless you use "-cpu host,migratable=off".
Something that allows disabling feature flags that still don't
have a name in QEMU would be useful for "-cpu
host,migratable=off" only (and that's an interesting suggestion).
But that's not the case here, I guess.
--
Eduardo
3:07 a.m.
On Wed, Jun 15, 2016 at 11:51:50AM -0300, Eduardo Habkost wrote:
We have that: it is "-feature" (or
"feature=off"). Features that
can't be configured in the command-line should never appear to
the guest unless you use "-cpu host,migratable=off".
Something that allows disabling feature flags that still don't
have a name in QEMU would be useful for "-cpu
host,migratable=off" only (and that's an interesting suggestion).
But that's not the case here, I guess.
Right, and I'm wondering whether something like that would be useful for
testing purposes. For example, I want to enable a CPUID feature on the
command line and see how the kernel I'm booting in the guest reacts. And
that feature bit is not necessarily known to qemu/kvm.
Can we, say, pass whole CPUID leafs to qemu to report to the guest?
I.e., something like:
... -cpuid=0x5,eax=0x40,ebx=0xdeadbeef,ecx=0xcaffee ...
and so on.
Would that be interesting to add to qemu? I'd find something like that
very useful for testing kernels...
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
12:53 a.m.
On 15/06/2016 16:25, Borislav Petkov wrote:
As to the error message, dear LKP friends, it happens because -cpu
kvm64
on native Intel hands in CPUID bits of the host, i.e., if you do this in
the guest:
$ grep epb /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush mmx fxsr sse sse2 syscall nx lm constant_tsc nopl eagerfpu pni cx16 x2apic
hypervisor epb
you should have "epb" there too which is among those bits.
Hmm, no, it doesn't work like that.
EPB is bit 3 of CPUID[6].ECX. Under KVM you should only ever see bit 2
of EAX set in that leaf (ARAT).
I can reproduce the same issue on an AMD host too by booting my
guest
with
"-cpu kvm64,vendor=GenuineIntel"
I cannot reproduce it with 4.6.0-rc3 in the (Fedora 22 AMD) host and
4.7.0-rc2 in the (Fedora 21) guest. QEMU is 2.4.1.
Paolo, Eduardo, question: can we hide certain CPUID bits from the
guest
when booting with -cpu kvm64?
In general, is there a way I can set or clear arbitrary CPUID bits so
that the guest sees what I want it to see?
And I don't mean the predefined CPUID flags which you toggle with "+" or
"-" followed by flag name. Because -cpu kvm64,-epb doesn't work.
It doesn't work because QEMU has no idea of what EPB even is. That bit
really shouldn't be set.
Can you bounce me the original report?
Paolo
3:23 a.m.
On Jun 15, 2016 7:25 AM, "Borislav Petkov" <bp(a)alien8.de> wrote:
On Wed, Jun 15, 2016 at 08:25:57PM +0800, kernel test robot wrote:
> [ 0.556833] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [ 0.559888] ------------[ cut here ]------------
> [ 0.559888] ------------[ cut here ]------------
> [ 0.561405] WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50
ex_handler_rdmsr_unsafe+0x44/0x70
> [ 0.561405] WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50
ex_handler_rdmsr_unsafe+0x44/0x70
> [ 0.567649] unchecked MSR access error: RDMSR from 0x1b0
> [ 0.567649] unchecked MSR access error: RDMSR from 0x1b0
Btw, Andy, this error message is completely useless - I
wanna know *where* the RDMSR in the code is, not point me at
ex_handler_rdmsr_unsafe().
Did the "Call Trace" not show up?
IOW, I wanna convert the current thing into this:
[ 0.028003] unchecked MSR access error: RDMSR from 0x1b0 at rIP: 0xffffffff81026d9f
[ 0.030343] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.032003] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[ 0.036003] unchecked MSR access error: WRMSR to 0x1b0 (tried to write
0x0000000000000006) at rIP: 0xffffffff81026de1
i.e.,
---
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index 4bb53b89f3c5..2028a5ad3433 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -46,8 +46,8 @@ EXPORT_SYMBOL(ex_handler_ext);
bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
struct pt_regs *regs, int trapnr)
{
- WARN_ONCE(1, "unchecked MSR access error: RDMSR from 0x%x\n",
- (unsigned int)regs->cx);
+ pr_warn_once("unchecked MSR access error: RDMSR from 0x%x at rIP:
0x%lx\n",
+ (unsigned int)regs->cx, regs->ip);
I have no fundamental issue adding ip to this, but let's keep it
WARN_ONCE (so we notice loudly and so we get the call trace) and use
%pF or whatever it's called instead of %lx.
Also, I want to add a variant of WARN that takes pt_regs as parameters
at some point. You'd get much better output. Even without that, Josh
Poimboeuf and I (mainly Josh) have some work slowly afoot that will
greatly improve call trace quality when crossing an exception
boundary.
--Andy
3:50 a.m.
On Wed, Jun 15, 2016 at 10:23:39AM -0700, Andy Lutomirski wrote:
Did the "Call Trace" not show up?
It did, but it is bollocks too:
[ 0.020003] ------------[ cut here ]------------
[ 0.024009] WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50
ex_handler_rdmsr_unsafe+0x6f/0x80
[ 0.026455] unchecked MSR access error: RDMSR from 0x1b0 at rIP: 0xffffffff81026d9f
[ 0.028008] Modules linked in:
[ 0.032008] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc3+ #26
[ 0.035185] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140531_083030-gandalf 04/01/2014
[ 0.036000] 0000000000000000 ffffffff81c03d20 ffffffff81298b65 ffffffff81c03d70
[ 0.036000] 0000000000000000 ffffffff81c03d60 ffffffff81050fdb 0000003200000001
[ 0.036000] ffffffff81c03e38 ffffffff816691a0 0000000000000000 ffffffff81d662e0
[ 0.036000] Call Trace:
[ 0.036000] [<ffffffff81298b65>] dump_stack+0x67/0x92
[ 0.036000] [<ffffffff81050fdb>] __warn+0xcb/0xf0
[ 0.036000] [<ffffffff8105104f>] warn_slowpath_fmt+0x4f/0x60
[ 0.036000] [<ffffffff81026d9f>] ? init_intel_energy_perf.part.3+0xf/0xd0
[ 0.036000] [<ffffffff810448ef>] ex_handler_rdmsr_unsafe+0x6f/0x80
[ 0.036000] [<ffffffff810449c9>] fixup_exception+0x39/0x50
[ 0.036000] [<ffffffff8101658f>] do_general_protection+0x7f/0x150
[ 0.036000] [<ffffffff816649bf>] general_protection+0x1f/0x30
[ 0.036000] [<ffffffff81026d9f>] ? init_intel_energy_perf.part.3+0xf/0xd0
[ 0.036000] [<ffffffff8102731f>] init_intel+0xdf/0x2b0
[ 0.036000] [<ffffffff8102597d>] identify_cpu+0x2ed/0x4f0
[ 0.036000] [<ffffffff81cdc1b8>] identify_boot_cpu+0x10/0x7a
[ 0.036000] [<ffffffff81cdc256>] check_bugs+0x9/0x2d
[ 0.036000] [<ffffffff81cd1ece>] start_kernel+0x3bd/0x3d9
[ 0.036000] [<ffffffff81cd1294>] x86_64_start_reservations+0x2f/0x31
[ 0.036000] [<ffffffff81cd13fe>] x86_64_start_kernel+0x168/0x176
[ 0.036007] ---[ end trace df7f3cc4a52dae6d ]---
I have no fundamental issue adding ip to this, but let's keep it
WARN_ONCE (so we notice loudly and so we get the call trace)
Bah, I'm sceptical about that.
and use %pF or whatever it's called instead of %lx.
Ok.
Also, I want to add a variant of WARN that takes pt_regs as
parameters
at some point. You'd get much better output. Even without that, Josh
Poimboeuf and I (mainly Josh) have some work slowly afoot that will
greatly improve call trace quality when crossing an exception
boundary.
Yes, because that call trace is almost worthless to me as the function
which actually causes it - init_intel_energy_perf - is not even on the
current stack frame.
And we don't really need the whole trace - we just need to be able to
say:
unchecked MSR access error: RDMSR from 0x1b0 at rIP: 0xffffffff81026d9f
(init_intel_energy_perf.part.3)
and that function name in there could probably be looked up with
kallsyms by doing something like "get me the function name containing
this rIP".
(I haven't even looked whether that's doable but it should be).
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
3:55 a.m.
On Wed, Jun 15, 2016 at 10:50 AM, Borislav Petkov <bp(a)alien8.de> wrote:
On Wed, Jun 15, 2016 at 10:23:39AM -0700, Andy Lutomirski wrote:
> Did the "Call Trace" not show up?
It did, but it is bollocks too:
[ 0.020003] ------------[ cut here ]------------
[ 0.024009] WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50
ex_handler_rdmsr_unsafe+0x6f/0x80
[ 0.026455] unchecked MSR access error: RDMSR from 0x1b0 at rIP: 0xffffffff81026d9f
[ 0.028008] Modules linked in:
[ 0.032008] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc3+ #26
[ 0.035185] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140531_083030-gandalf 04/01/2014
[ 0.036000] 0000000000000000 ffffffff81c03d20 ffffffff81298b65 ffffffff81c03d70
[ 0.036000] 0000000000000000 ffffffff81c03d60 ffffffff81050fdb 0000003200000001
[ 0.036000] ffffffff81c03e38 ffffffff816691a0 0000000000000000 ffffffff81d662e0
[ 0.036000] Call Trace:
[ 0.036000] [<ffffffff81298b65>] dump_stack+0x67/0x92
[ 0.036000] [<ffffffff81050fdb>] __warn+0xcb/0xf0
[ 0.036000] [<ffffffff8105104f>] warn_slowpath_fmt+0x4f/0x60
[ 0.036000] [<ffffffff81026d9f>] ? init_intel_energy_perf.part.3+0xf/0xd0
[ 0.036000] [<ffffffff810448ef>] ex_handler_rdmsr_unsafe+0x6f/0x80
[ 0.036000] [<ffffffff810449c9>] fixup_exception+0x39/0x50
[ 0.036000] [<ffffffff8101658f>] do_general_protection+0x7f/0x150
[ 0.036000] [<ffffffff816649bf>] general_protection+0x1f/0x30
[ 0.036000] [<ffffffff81026d9f>] ?
init_intel_energy_perf.part.3+0xf/0xd0
Isn't it this one?
There's a general bug where we have bogus '?' entries when tracing
through an exception frame, but I think we should fix that
generically. I have a really ugly patch, and I think that fixing it
better is in Josh's queue. If we fix it generically, then we get this
benefit everywhere in the kernel.
[ 0.036000] [<ffffffff8102731f>] init_intel+0xdf/0x2b0
[ 0.036000] [<ffffffff8102597d>] identify_cpu+0x2ed/0x4f0
[ 0.036000] [<ffffffff81cdc1b8>] identify_boot_cpu+0x10/0x7a
[ 0.036000] [<ffffffff81cdc256>] check_bugs+0x9/0x2d
[ 0.036000] [<ffffffff81cd1ece>] start_kernel+0x3bd/0x3d9
[ 0.036000] [<ffffffff81cd1294>] x86_64_start_reservations+0x2f/0x31
[ 0.036000] [<ffffffff81cd13fe>] x86_64_start_kernel+0x168/0x176
[ 0.036007] ---[ end trace df7f3cc4a52dae6d ]---
> I have no fundamental issue adding ip to this, but let's keep it
> WARN_ONCE (so we notice loudly and so we get the call trace)
Bah, I'm sceptical about that.
I'm not. If %pF points at some silly helper, we still want the frames below it.
> and use %pF or whatever it's called instead of %lx.
Ok.
> Also, I want to add a variant of WARN that takes pt_regs as parameters
> at some point. You'd get much better output. Even without that, Josh
> Poimboeuf and I (mainly Josh) have some work slowly afoot that will
> greatly improve call trace quality when crossing an exception
> boundary.
Yes, because that call trace is almost worthless to me as the function
which actually causes it - init_intel_energy_perf - is not even on the
current stack frame.
And we don't really need the whole trace - we just need to be able to
say:
unchecked MSR access error: RDMSR from 0x1b0 at rIP: 0xffffffff81026d9f
(init_intel_energy_perf.part.3)
and that function name in there could probably be looked up with
kallsyms by doing something like "get me the function name containing
this rIP".
(I haven't even looked whether that's doable but it should be).
%pF.
--Andy
4:07 a.m.
On Wed, Jun 15, 2016 at 10:55:34AM -0700, Andy Lutomirski wrote:
Isn't it this one?
Yes, it is.
I'm not. If %pF points at some silly helper, we still want the
frames below it.
Why silly helper? It points to the rIP where the *MSR instruction is.
Can't get more precise than that.
And yes, %pF is better:
[ 0.030879] unchecked MSR access error: RDMSR from 0x1b0 at rIP: 0xffffffff81026d9f
(init_intel_energy_perf.part.3+0xf/0xd0)
Ok, I'll send a patch.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
4:12 a.m.
On Wed, Jun 15, 2016 at 11:07 AM, Borislav Petkov <bp(a)alien8.de> wrote:
On Wed, Jun 15, 2016 at 10:55:34AM -0700, Andy Lutomirski wrote:
> Isn't it this one?
Yes, it is.
> I'm not. If %pF points at some silly helper, we still want the frames below it.
Why silly helper? It points to the rIP where the *MSR instruction is.
Can't get more precise than that.
A hypothetical helper.
void do_thing(unsigned long msr)
{
rdmsr(...);
}
void actual_problem(void)
{
do_thing(0xbaadc0de);
}
I want to see actual_problem in the log.
--Andy
4:23 a.m.
On Wed, Jun 15, 2016 at 11:12:37AM -0700, Andy Lutomirski wrote:
I want to see actual_problem in the log.
So the optimal thing to do for that is to return an error to the calling
site which says "exception got handled" and then the *calling* site can
dump_stack().
And the old code did that:
static inline unsigned long long native_read_msr_safe(unsigned int msr,
int *err)
{
DECLARE_ARGS(val, low, high);
asm volatile("2: rdmsr ; xor %[err],%[err]\n"
"1:\n\t"
".section .fixup,\"ax\"\n\t"
"3: mov %[fault],%[err] ; jmp 1b\n\t"
".previous\n\t"
_ASM_EXTABLE(2b, 3b)
: [err] "=r" (*err), EAX_EDX_RET(val, low, high)
: "c" (msr), [fault] "i" (-EIO));
^^^^
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
4:44 a.m.
On Wed, Jun 15, 2016 at 11:23 AM, Borislav Petkov <bp(a)alien8.de> wrote:
On Wed, Jun 15, 2016 at 11:12:37AM -0700, Andy Lutomirski wrote:
> I want to see actual_problem in the log.
So the optimal thing to do for that is to return an error to the calling
site which says "exception got handled" and then the *calling* site can
dump_stack().
And the old code did that:
static inline unsigned long long native_read_msr_safe(unsigned int msr,
int *err)
{
DECLARE_ARGS(val, low, high);
asm volatile("2: rdmsr ; xor %[err],%[err]\n"
"1:\n\t"
".section .fixup,\"ax\"\n\t"
"3: mov %[fault],%[err] ; jmp 1b\n\t"
".previous\n\t"
_ASM_EXTABLE(2b, 3b)
: [err] "=r" (*err), EAX_EDX_RET(val, low, high)
: "c" (msr), [fault] "i" (-EIO));
^^^^
Then we end up with bloat. The current thing generates very compact code.
--Andy
2286
days inactive
2286
days old
11 comments
5 participants
participants (5)
-
Andy Lutomirski -
Borislav Petkov -
Eduardo Habkost -
kernel test robot -
Paolo Bonzini