diff options
| author | Hugh Dickins <hugh@veritas.com> | 2007-11-28 18:57:12 +0000 |
|---|---|---|
| committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-11-28 11:04:28 -0800 |
| commit | 09f345da758fca1222b0971b65b2fddbdf78bb83 (patch) | |
| tree | 1a316a3a157a080eba3b98f25b69e0eb243ac6e9 /mm/page_alloc.c | |
| parent | e84e2e132c9c66d8498e7710d4ea532d1feaaac5 (diff) | |
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/page_alloc.c')
| -rw-r--r-- | mm/page_alloc.c | 1 |
1 files changed, 0 insertions, 1 deletions
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 12376ae3f73..4ffed1cd158 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. |