summaryrefslogtreecommitdiffstats
path: root/fs/ext3/fsync.c
diff options
context:
space:
mode:
authorDavid Gibson2005-11-24 03:34:56 +0100
committerPaul Mackerras2005-11-25 12:12:45 +0100
commit9a94c5793a7b44720f19ebb71b636bc9c31b44d8 (patch)
treedf25ab16bb1e586d671160dd26d3117aa43d77cf /fs/ext3/fsync.c
parentMerge ../linux-2.6 (diff)
downloadkernel-qcow2-linux-9a94c5793a7b44720f19ebb71b636bc9c31b44d8.tar.gz
kernel-qcow2-linux-9a94c5793a7b44720f19ebb71b636bc9c31b44d8.tar.xz
kernel-qcow2-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 'fs/ext3/fsync.c')
0 files changed, 0 insertions, 0 deletions