> I've seen a number of oops reports similar to this, and it appears that
> something is freeing a dentry or inode when it's still in use. Then the
> next call that finds the dentry on a list, typically select_dcache or
> do_follow_link, gets a trash pointer and oopses.
>
> I haven't been able to see a common cause to focus a search for the
> problem, but things to look for would be an extra dput() or iput() when
> there's a remaining reference to the dentry or inode.
turn SADISTIC_KMALLOC on (is there any slab.c equivalent for this?), this
speeds up the crash, maybe this way we get a better call trace.
-- mingo
ps. with ktrace you get a trace of the last 100 function entries on every
oops, which should thus show all previous VFS activity. You can even
selectively trace only VFS activities.