summaryrefslogtreecommitdiffstats
path: root/mm
diff options
context:
space:
mode:
authorHugh Dickins <hugh@veritas.com>2007-11-28 19:57:12 +0100
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-11-28 20:04:28 +0100
commit09f345da758fca1222b0971b65b2fddbdf78bb83 (patch)
tree1a316a3a157a080eba3b98f25b69e0eb243ac6e9 /mm
parenttmpfs: restore missing clear_highpage (diff)
downloadlinux-09f345da758fca1222b0971b65b2fddbdf78bb83.tar.xz
linux-09f345da758fca1222b0971b65b2fddbdf78bb83.zip
prep_zero_page: remove bogus BUG_ON
2.6.11 gave __GFP_ZERO's prep_zero_page a bogus "highmem may have to wait" assertion. Presumably added under the misconception that clear_highpage uses nonatomic kmap; but then and now it uses kmap_atomic, so no problem. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm')
-rw-r--r--mm/page_alloc.c1
1 files changed, 0 insertions, 1 deletions
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 12376ae3f733..4ffed1cd158b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -305,7 +305,6 @@ static inline void prep_zero_page(struct page *page, int order, gfp_t gfp_flags)
{
int i;
- VM_BUG_ON((gfp_flags & (__GFP_WAIT | __GFP_HIGHMEM)) == __GFP_HIGHMEM);
/*
* clear_highpage() will use KM_USER0, so it's a bug to use __GFP_ZERO
* and __GFP_HIGHMEM from hard or soft interrupt context.