summaryrefslogtreecommitdiff
path: root/fs/dlm/requestqueue.c
diff options
context:
space:
mode:
authorBoris Ostrovsky <boris.ostrovsky@oracle.com>2019-09-30 23:44:41 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-11-06 15:08:26 +0300
commit7ed7e30ca56ca3c95c0ce2f54df430354df0b8da (patch)
tree45db89c28e71a12ac91d4ec8465cfcdcdf179aed /fs/dlm/requestqueue.c
parent3876cf044811c05efd24352c7cf15f11f0b8a515 (diff)
downloadlinux-7ed7e30ca56ca3c95c0ce2f54df430354df0b8da.tar.xz
x86/xen: Return from panic notifier
[ Upstream commit c6875f3aacf2a5a913205accddabf0bfb75cac76 ] Currently execution of panic() continues until Xen's panic notifier (xen_panic_event()) is called at which point we make a hypercall that never returns. This means that any notifier that is supposed to be called later as well as significant part of panic() code (such as pstore writes from kmsg_dump()) is never executed. There is no reason for xen_panic_event() to be this last point in execution since panic()'s emergency_restart() will call into xen_emergency_restart() from where we can perform our hypercall. Nevertheless, we will provide xen_legacy_crash boot option that will preserve original behavior during crash. This option could be used, for example, if running kernel dumper (which happens after panic notifiers) is undesirable. Reported-by: James Dingwall <james@dingwall.me.uk> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'fs/dlm/requestqueue.c')
0 files changed, 0 insertions, 0 deletions