Re: [RFC][PATCH 0/6] mm, highmem: kmap_atomic rework
From: Peter Zijlstra <peterz@infradead.org>
Date: 2010-08-20 14:38:41
Also in:
linux-mm, lkml
On Thu, 2010-08-19 at 14:31 -0700, Andrew Morton wrote:
On Thu, 19 Aug 2010 22:13:17 +0200 Peter Zijlstra [off-list ref] wrote:quoted
This patch-set reworks the kmap_atomic API to be a stack based, instead of static slot based. Some might remember this from last year, some not ;-) The advantage is that you no longer need to worry about KM_foo, the disadvantage is that kmap_atomic/kunmap_atomic now needs to be strictly nested (CONFIG_HIGHMEM_DEBUG should complain in case its not) -- and of course its a big massive patch changing a widely used API.Nice. That fixes the "use of irq-only slots from interrupts-on context" bugs which people keep adding.
Ah, I should add a: WARN_ON_ONCE(in_irq() && !irqs_disabled()); like check to ensure people don't use kmap_atomic() in nestable IRQ contexts (nestable IRQ context is bad anyway) the old debug code I deleted did something similar.
We don't have any checks in there for the stack overflowing?
+#ifdef CONFIG_DEBUG_HIGHMEM + BUG_ON(idx > KM_TYPE_NR); +#endif Seems to be that.
Did you add every runtime check you could possibly think of? kmap_atomic_idx_push() and pop() don't have much in there. It'd be good to lard it up with runtime checks for at least a few weeks.
Right, so I currently have: - stack size check in push/pop - proper nesting check in pop (verifies that the vaddr you try to unmap is indeed the top most on the stack) Aside from the proposed no irq-nesting thing to avoid unbounded recursion I can't really come up with more creative abuse.
Well, there's that monster conversion patch. How's about you temporarily do #define kmap_atomic(x, arg...) __kmap_atomic(x) so for a while, both kmap_atomic(a, KM_foo) and kmap_atomic(a) are turned into __kmap_atomic(a). Once all the dust has settled, pull that out again?
Ah, that's a nifty trick, let me try that. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>