Re: [x86] 5ac0c41bf3: WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe

From: Andy Lutomirski
Date: Wed Jun 15 2016 - 13:56:00 EST


On Wed, Jun 15, 2016 at 10:50 AM, Borislav Petkov <bp@xxxxxxxxx> 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