On Fri, 28 Jul 2006, Pekka Enberg wrote:
> > [ 57.976447] [<ffffffff802542fc>] __lock_acquire+0x8cc/0xcb0
> > [ 57.976562] [<ffffffff80254a02>] lock_acquire+0x52/0x70
> > [ 57.976675] [<ffffffff8028f201>] kmem_cache_free+0x141/0x210
> > [ 57.976790] [<ffffffff804a6b74>] _spin_lock+0x34/0x50
> > [ 57.976903] [<ffffffff8028f201>] kmem_cache_free+0x141/0x210
> > [ 57.977018] [<ffffffff8028f388>] slab_destroy+0xb8/0xf0
Huh? _spin_lock calls kmem_cache_free?
> cache_reap
> reap_alien (grabs l3->alien[node]->lock)
> __drain_alien_cache
> free_block
> slab_destroy (slab management off slab)
> kmem_cache_free
> __cache_free
> cache_free_alien (recursive attempt on l3->alien[node] lock)
>
> Christoph?
This should not happen. __drain_alien_cache frees node local elements
thus cache_free_alien should not be called. However, if the slab
management was allocated on a different node from the slab data then we
may have an issue. However, both slab managemnt and the slab data are
allocated on the same node (with alloc_pages_node() and kmalloc_node).
If something went wrong with kmalloc_node or alloc_pages_node (fallback?)
then we may have an issue. Guess we need to look into this some more.
Alok, have you thought about this issue before?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
