Messages in this thread Patch in this message | | | From | hooanon05@yahoo ... | Subject | Re: Q, slab, kmemleak_erase() and redzone? | Date | Tue, 24 Nov 2009 16:06:22 +0900 |
| |
Pekka Enberg: > We are setting an element in the per CPU array to NULL so the the > kmemleak code in ____cache_alloc() is safe. Red-zoning is done at the > _object_ which is not touched by kmemleak. Looking at the oops, it > does seem likely that you have a bug in your module (or in some other > part of the kernel).
Thanks for reply. In ____cache_alloc(), the variable 'ac' is assigned before cache_alloc_refill() call, and it is used for the parameter of kmemleak_erase(). The value may be changed by cache_alloc_refill(), isn't it? In this case, kmemleak_erase() receives the incorrect pointer and sets NULL to somewhere else which may be redzone?
How about this fix? If cpu_cache_get() call is heavy and we cannot ignore it when KMEMLEAK is disabled, then a new wrapper may be necessary.
diff --git a/mm/slab.c b/mm/slab.c index 71e0a1f..3f3e018 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3104,6 +3104,7 @@ static inline void *____cache_alloc(struct kmem_cache *cachep, gfp_t flags) } else { STATS_INC_ALLOCMISS(cachep); objp = cache_alloc_refill(cachep, flags); + ac = cpu_cache_get(cachep); } /* * To avoid a false negative, if an object that is in one of the
J. R. Okajima
| |