On Mon, Mar 19, 2012 at 6:31 PM, Christoph Lameter <cl@xxxxxxxxx> wrote: > On Mon, 19 Mar 2012, Sasha Levin wrote: > >> On Mon, Mar 19, 2012 at 3:56 PM, Christoph Lameter <cl@xxxxxxxxx> wrote: >> > This is sually something causing memory corruption. Please enable >> > debugging to get backtrace that help to debutg this. CONFIG_SLUB_DEBUG_ON >> > will do the trick or passing "slub_debug" on the kernel command line. >> >> The kernel was compiled with SLUB_DEBUG_ON, there's nothing coming out >> of the slub before that hang message, nor after it. > > Ok looking at the backtrace: This is kmem_cache_destroy and not the usual > failure following a pointer in alloc / free. > > netfilter calls kmem_cache_destroy which calls into sysfs functions and > there the hang occurs. > > Did you try to see if lockdep can detect any serialization problems ? > > Is kmem_cache_destroy called with any locks held? Interrupts off? > lockdep listed all the held locks there. I've mentioned that it looks very similar to https://lkml.org/lkml/2012/1/14/45 where the userspace helper tried to read from the sysfs files, but got into a deadlock since the kernel side held them before it called the usermode helper. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
