On Fri, 28 Mar 2008, Christoph Lameter wrote:.. and clear_highpage() does: void *kaddr = kmap_atomic(page, KM_USER0); clear_page(kaddr); .. where kmap_atomic() on x86 does: kmap_atomic() -> kmap_atomic_prot() -> debug_kmap_atomic_prot() -> if (in_irq()) WARN_ON_ONCE() none of which are at all conditional on __GFP_HIGHMEM. But none of this is relevant. The warning possibly didn't even come from slub, it just made me look at it - because *something* is doing GFP_ATOMIC together with __GFP_ZERO, and it became obvious that SLUB is one potential cause of that. And the SLUB case simply isn't valid! No. Dammit, the bug is in SLUB. If SLUB *ever* calls the page allocator with __GFP_ZERO set, it's a bug, and that has nothing to do with GFP_ATOMIC or anything else. Because SLUB uses its own logic for clearing the result. Why cannot you just admit it? Now, _outside_ of SLUB there appear to be other users too, and those users need to either be fixed or we need to allow __GFP_ZERO togethe with GFP_ATOMIC. But the fact is, SLUB had a really stupid bug that it shouldn't have had. Linus --
| Linus Torvalds | Re: O_DIRECT question |
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Andrew Morton | -mm merge plans for 2.6.23 |
| David Miller | Re: [PATCH] net: Fix the prototype of call_netdevice_notifiers |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [GIT]: Networking |
| Radu Rendec | htb parallelism on multi-core platforms |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
