summaryrefslogtreecommitdiffstats
path: root/kernel/crash_dump.c
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2005-11-24 13:34:56 +1100
committerPaul Mackerras <paulus@samba.org>2005-11-25 22:12:45 +1100
commit9a94c5793a7b44720f19ebb71b636bc9c31b44d8 (patch)
treedf25ab16bb1e586d671160dd26d3117aa43d77cf /kernel/crash_dump.c
parent26925c5910ab77fc95b4d8bb6d98780b50ab1e5a (diff)
downloadtalos-op-linux-9a94c5793a7b44720f19ebb71b636bc9c31b44d8.tar.gz
talos-op-linux-9a94c5793a7b44720f19ebb71b636bc9c31b44d8.zip
[PATCH] powerpc: More hugepage boundary case fixes
Blah. The patch [0] I recently sent fixing errors with in_hugepage_area() and prepare_hugepage_range() for powerpc itself has an off-by-one bug. Furthermore, the related functions touches_hugepage_*_range() and within_hugepage_*_range() are also buggy. Some of the bugs, like those addressed in [0] originated with commit 7d24f0b8a53261709938ffabe3e00f88f6498df9 where we tweaked the semantics of where hugepages are allowed. Other bugs have been there essentially forever, and are due to the undefined behaviour of '<<' with shift counts greater than the type width (LOW_ESID_MASK could return non-zero for high ranges with the right congruences). The good news is that I now have a testsuite which should pick up things like this if they creep in again. [0] "powerpc-fix-for-hugepage-areas-straddling-4gb-boundary" Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'kernel/crash_dump.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud