summaryrefslogtreecommitdiff
path: root/util_lib/sha256.c
diff options
context:
space:
mode:
authorNeil Horman <nhorman@tuxdriver.com>2008-05-20 11:26:40 -0400
committerSimon Horman <horms@verge.net.au>2008-05-21 10:49:51 +1000
commitdad9f01c556c69c432f3b145e2947dcd5e7626ca (patch)
treee1089d57bce40563b2c44c408446c75e897cf08a /util_lib/sha256.c
parent595994920f19891f50b41d24cbd808beb0ae8ea9 (diff)
PPC64: ensure that extra rtas segment is a multiple of PAGE_SIZE
kexec on ppc64 systems, include an extra PT_LOAD segment if the rtas memory hits the stored kdump kernel image. While the rtas area is memory mapped (implying that it begins and ends on a page boundary), the whole of the mapped region is not consumed by the rtas features (the remaining area just returns 0's). This unused area is not accounted in the rtas prom, which is used to populate the proc files which export the size information that is used to define the mapped memory region (/proc/device-tree/rtas/rtas-size). Since this is the data that kexec uses to generate the PT_LOAD segment, we wind up with a PT_LOAD segment that incorrectly contains a partial page. This causes things like makedumpfile to fail, since it reads memory in page sized chunks, and fails on the inability to read only part of a page. This patch corrects that by rounding the extra segment size up the next whole page size. This is safe, since the rtas area is mapped to a whole page range. I've tested on both 4k and 64k configured kernels on ppc64 and found that it works well. Regards Neil Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Diffstat (limited to 'util_lib/sha256.c')
0 files changed, 0 insertions, 0 deletions