Messages in this thread | | | Date | Sun, 22 Nov 2009 11:35:17 +0200 | Subject | Re: Q, slab, kmemleak_erase() and redzone? | From | Pekka Enberg <> |
| |
On Fri, Nov 20, 2009 at 6:14 PM, <hooanon05@yahoo.co.jp> wrote: > in short: Is it safe to assign NULL to the un-adjusted pointer in > kmemleak_erase()? > > in long: > I've met a strange redzone warning at deleting a module. > > ---------------------------------------------------------------------- > slab error in verify_redzone_free(): cache `size-256': memory outside object was overwritten > Pid: 5080, comm: modprobe Not tainted 2.6.32-rc7aufsD #320 > Call Trace: > [<ffffffff811010d1>] ? dbg_redzone2+0x31/0x70 > [<ffffffff81101371>] __slab_error+0x21/0x30 > [<ffffffff811022cd>] cache_free_debugcheck+0x1fd/0x300 > [<ffffffff811041e5>] ? __kmem_cache_destroy+0x65/0x110 > [<ffffffff81103bc0>] kfree+0x1c0/0x260 > [<ffffffff811041e5>] __kmem_cache_destroy+0x65/0x110 > [<ffffffff81104336>] kmem_cache_destroy+0xa6/0x100 > [<ffffffffa03130b4>] au_cache_fin+0xb4/0xf0 [aufs] > [<ffffffff81458387>] ? _write_unlock+0x57/0x70 > [<ffffffffa0348c75>] aufs_exit+0x15/0x39 [aufs] > [<ffffffff81095cdb>] sys_delete_module+0x19b/0x260 > [<ffffffff81087e3d>] ? trace_hardirqs_on_caller+0x14d/0x1a0 > [<ffffffff8145797e>] ? trace_hardirqs_on_thunk+0x3a/0x3f > [<ffffffff810127c2>] system_call_fastpath+0x16/0x1b > ffff88000e87aa40: redzone 1:0xd84156c5635688c0, redzone 2:0x0. > ---------------------------------------------------------------------- > > When delete_module(2) removes aufs.ko, aufs_exit() calls > kmem_cache_destroy() (SLAB) to remove some aufs specific caches whose > name are NOT 'size-256.' Diving into kmemcache, I found the trigger is > in __kmem_cache_destroy(), > for_each_online_cpu(i) > kfree(cachep->array[i]); > The 'cachep->array[i]' is in 'size-256' cache, and kfree() for it > produced the warning. > > At first, I thought I made mistakes in my module and corruped > memory. But I could not find such bug. > Inserting some code to check the correctness of cachep->array[i] for > size-256 everywhere led me to kmemleak_erase() in ____cache_alloc(). > > __cache_alloc() > { > objp = __do_cache_alloc(cachep, flags); > ::: > objp = cache_alloc_debugcheck_after(cachep, flags, objp, caller); > ::: > return objp; > } > > __do_cache_alloc() > { > ::: > objp = ____cache_alloc(cache, flags); > ::: > return objp; > } > > ____cache_alloc() > { > objp = ac->entry[--ac->avail]; > or > objp = cache_alloc_refill(cachep, flags); > ::: > kmemleak_erase(&ac->entry[ac->avail]); > return objp; > } > > kmemleak_erase(void **ptr) > { > *ptr = NULL; > } > > cache_alloc_debugcheck_after() adjusts the passed objp by > objp += obj_offset(cachep); > which is 4 or 8 bytes when CONFIG_DEBUG_SLAB is enabled (also > cache_alloc_refill() may return NULL). > In other words, the passed pointer to kmemleak_erase() is not adjusted > yet. > Is it safe to assign NULL to the un-adjusted pointer in kmemleak_erase()?
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).
Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |