On Tue, 9 Sep 2014 12:12:44 -0400 Jeff Layton <jlayton@xxxxxxxxxxxxxxx> wrote: > On Tue, 9 Sep 2014 08:42:11 -0700 > Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > 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. > > Ok. So I'm guessing that means that the current scheme of doing a > d_drop/d_add is not valid. d_drop doesn't remove the dentry from the > i_alias list. > > It looks like the first call there should just be doing a d_delete > instead, since it's trying to turn the thing into a negative dentry. (cc'ing Neil B.) ...and I'd hazard a guess that 4fa2c54b5198d might be the culprit. You might want to try backing that out and see if it's still reproducible. Neil, any thoughts? -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
