Re: Boot failure with slab debugging patch

[Andrew Morton]

David Howells <dhowells@xxxxxxxxxx> wrote:
>
> This patch in 2.6.13-rc5-mm1:
> 
>  	slab-leak-detector-give-longer-traces.patch
> 
>  Causes the kernel to die with an oops on my test box during boot (see
>  attached), just about here, I think:
> 
>  	static void inline *
>  	cache_alloc_debugcheck_after(kmem_cache_t *cachep,
>  				unsigned int __nocast flags, void *objp, void *caller)
>  	{
>  		if (!objp)	
>  			return objp;
>  		if (cachep->flags & SLAB_POISON) {
>  	#ifdef CONFIG_DEBUG_PAGEALLOC
>  			if ((cachep->objsize % PAGE_SIZE) == 0 && OFF_SLAB(cachep))
>  				kernel_map_pages(virt_to_page(objp), cachep->objsize/PAGE_SIZE, 1);
>  			else
>  				check_poison_obj(cachep, objp);
>  	#else
>  			check_poison_obj(cachep, objp);
>  	#endif
>  			poison_obj(cachep, objp, POISON_INUSE);
>  		}
>  		if (cachep->flags & SLAB_STORE_USER) {
>  			*dbg_userword1(cachep, objp) = caller; /* address(0) */
>  			*dbg_userword2(cachep, objp) = __builtin_return_address(1);
>  --->			*dbg_userword3(cachep, objp) = __builtin_return_address(2);
>  		}
> 
> 
>  Shortly after the call instruction to dbg_userword3().
> 
>  Repealing that patch permits the kernel to work again.

Yup, sorry about that.  For some system calls the __builtin_return_address()
just walks off the top of the stack.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/