On Fri, Mar 8, 2013 at 3:07 PM, Dave Jones <da...@redhat.com> wrote: > > Ok, got something more meaningful out of the lookup_slow trace. > > [ 66.082984] parent->dname.name (06b6b6b6b6b6b6b) > [ 66.083637] parent = > > At first I thought AH-HA! SLAB POISON! > But look closer.. it's shifted by 8 bits.
Or just the high byte has been cleared. But yeah, if the parent has been free'd then that certainly explains why the "impossible" test of nd->inode != parent->d_inode would trigger. And it would explain any odd crashes at lookup time too. In particular, the NULL pointer one you reference seems to be dir->i_op->lookup being NULL, so calling it (understandable) ends up doing bad things. I really don't understand how the parent could be free'd early. Dentries are freed by RCU, and the dentry lookup code is some of the most well-tested out there. I don't see how /proc could mess that up, unless it just completely screws up some refcounting thing or other. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/