Re: kernel BUG in fs/dcache.c running nfs

Christoph Hellwig
2014-09-09T15:42:12Z

On Tue, Sep 09, 2014 at 10:59:18AM -0400, Jeff Layton wrote:
> > [ 5497.405585] [<ffffffff8135d0c1>] nfs4_do_open.constprop.84+0x681/0x960
> > [ 5497.405585] [<ffffffff8135d459>] nfs4_atomic_open+0x9/0x20
> > [ 5497.405585] [<ffffffff8136cc3d>] nfs4_file_open+0xcd/0x1b0
> > [ 5497.405585] [<ffffffff811b8092>] do_dentry_open.isra.13+0x1f2/0x320
> > [ 5497.405585] [<ffffffff811b82ad>] finish_open+0x1d/0x30
> > [ 5497.405585] [<ffffffff811c98e9>] path_openat+0xb9/0x670
> > [ 5497.405585] [<ffffffff811ca26e>] do_filp_open+0x3e/0xa0
> > [ 5497.405585] [<ffffffff811b95cc>] do_sys_open+0x13c/0x230
> > [ 5497.405585] [<ffffffff811b96dd>] SyS_open+0x1d/0x20
> > [ 5497.405585] [<ffffffff81d9f5a9>] system_call_fastpath+0x16/0x1b
> >
>
> Odd...
>
> It looks like you hit the BUG() in d_instantiate.
>
> I don't see any calls to d_instantiate in the current nfs_code (aside
> from the one in nfs_lookup, and I don't think that's getting called
> here). d_instantiate is called by d_add though, and that gets called
> from nfs_atomic_open. Is that what happened here?
>
> Maybe you can use gdb to figure out what line of code
> "nfs4_do_open.constprop.84+0x681" actually is?

My gdb can't cope with these constprop expressions unfortunately.

But when you remove the questionable symbols as I've done above it's
pretty clear that this must be the

nfs4_atomic_open
-> nfs4_do_open
-> _nfs4_do_open
-> _nfs4_open_and_get_state
-> d_add
-> d_instantiate

call chain. There is heavy inlining going on inside nfs4file.c, and
d_add now is a simple inline around d_instantiate and d_rehash.
>
> --
> Jeff Layton <jlayton@primarydata.com>
---end quoted text---