summaryrefslogtreecommitdiffstats
path: root/drivers/hv/hv_utils_transport.h
diff options
context:
space:
mode:
authorXunlei Pang <xlpang@redhat.com>2016-05-23 16:24:10 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2016-05-23 17:04:14 -0700
commit9b492cf58077a0254eb4b9574029ac6e79add9f9 (patch)
tree7f723acccb7706d1c38aa4573f469d5b633cf20c /drivers/hv/hv_utils_transport.h
parent9eb8a659dea694b0dcbd6287f6b1fbdc523b80bc (diff)
downloadop-kernel-dev-9b492cf58077a0254eb4b9574029ac6e79add9f9.zip
op-kernel-dev-9b492cf58077a0254eb4b9574029ac6e79add9f9.tar.gz
kexec: introduce a protection mechanism for the crashkernel reserved memory
For the cases that some kernel (module) path stamps the crash reserved memory(already mapped by the kernel) where has been loaded the second kernel data, the kdump kernel will probably fail to boot when panic happens (or even not happens) leaving the culprit at large, this is unacceptable. The patch introduces a mechanism for detecting such cases: 1) After each crash kexec loading, it simply marks the reserved memory regions readonly since we no longer access it after that. When someone stamps the region, the first kernel will panic and trigger the kdump. The weak arch_kexec_protect_crashkres() is introduced to do the actual protection. 2) To allow multiple loading, once 1) was done we also need to remark the reserved memory to readwrite each time a system call related to kdump is made. The weak arch_kexec_unprotect_crashkres() is introduced to do the actual protection. The architecture can make its specific implementation by overriding arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres(). Signed-off-by: Xunlei Pang <xlpang@redhat.com> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Dave Young <dyoung@redhat.com> Cc: Minfei Huang <mhuang@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Baoquan He <bhe@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/hv/hv_utils_transport.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud