"K. Y. Srinivasan" <k...@microsoft.com> writes: > From: Vitaly Kuznetsov <vkuzn...@redhat.com> > > current_pt_regs() returns regs of the userspace process and in case of > kernel crash this is not what we need to report. E.g. when we trigger > crash with sysrq we see the following: > ... > RIP: 0010:[<ffffffff815b8696>] [<ffffffff815b8696>] > sysrq_handle_crash+0x16/0x20 > RSP: 0018:ffff8800db0a7d88 EFLAGS: 00010246 > RAX: 000000000000000f RBX: ffffffff820a0660 RCX: 0000000000000000 > ... > at the same time current_pt_regs() give us: > ip=7f899ea7e9e0, ax=ffffffffffffffda, bx=26c81a0, cx=7f899ea7e9e0, ... > These registers come from the userspace process triggered the crash. As we > don't even know which process it was this information is rather useless. > > When kernel crash happens proper regs are being passed to all receivers on > the die_chain (and panic_notifier_list is being notified with the string > passed to panic() only). Let's move our Hyper-V MSR reporter there. This > change has the following implication: when panic() is called manually from > some other part of kernel we won't be reporting crash to the hypervisor > (but we have no valuable information to report anyway).
We can, actually, do better: we can has this reporter in _both_ notification chains (with a static preventng double reporting). In this case we'll have panics reported on e.g BUG_ON() As this patch is still not merged I'll fix and resend instead of creating a separate patch. -- Vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
