From: NeilBrown <neilb@suse.de>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Jeff Layton <jeff.layton@primarydata.com>,
Christoph Hellwig <hch@infradead.org>,
linux-nfs@vger.kernel.org
Subject: Re: kernel BUG in fs/dcache.c running nfs
Date: Mon, 29 Sep 2014 11:35:19 +1000 [thread overview]
Message-ID: <20140929113519.30292efb@notabene.brown> (raw)
In-Reply-To: <20140926230801.GR7996@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
On Sat, 27 Sep 2014 00:08:01 +0100 Al Viro <viro@ZenIV.linux.org.uk> wrote:
> On Wed, Sep 10, 2014 at 01:57:39PM +1000, NeilBrown wrote:
>
> > The d_drop();d_add(); pattern is used a number of times in NFS, but what I
> > didn't notice before is that it is only used if ->d_inode is NULL.
>
> And the point of that "pattern" would be...? If dentry is already negative
> and hashed, it does nothing whatsoever. If it is negative and unhashed,
> d_drop() is a no-op, obviously. And if it's positive, we get a nice
> shiny oops.
>
> Where are we doing anything of that sort, anyway? I see a bloody odd
> instance in nfs_atomic_open() and that's it. Note that nfs_instantiate()
> is different (and not necessary nice - that d_drop() in case when this
> sucker is called from mkdir() is asking for races with mount()). How
> do we get a positive hashed dentry there, anyway?
Apart from nfs_atomic_open() and nfs_instantiate(), the main one is
in _nfs4_open_and_get_state:
/* FIXME: Is this d_drop() ever needed? */
d_drop(dentry);
dentry = d_add_unique(dentry, igrab(state->inode));
maybe you can answer the question in the comment
nfs_link also has
d_drop(dentry);
error = NFS_PROTO(dir)->link(inode, dir, &dentry->d_name);
if (error == 0) {
ihold(inode);
d_add(dentry, inode);
}
which is similar.
Thanks,
NeilBrown
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2014-09-29 1:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-08 14:45 kernel BUG in fs/dcache.c running nfs Christoph Hellwig
2014-09-09 14:59 ` Jeff Layton
2014-09-09 15:42 ` Christoph Hellwig
2014-09-09 16:12 ` Jeff Layton
2014-09-09 16:15 ` Jeff Layton
2014-09-09 17:50 ` Jeff Layton
2014-09-10 3:57 ` NeilBrown
2014-09-10 11:59 ` Jeff Layton
2014-09-11 6:20 ` NeilBrown
2014-09-26 23:08 ` Al Viro
2014-09-29 1:35 ` NeilBrown [this message]
2014-09-09 16:59 ` Trond Myklebust
2014-09-09 17:28 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140929113519.30292efb@notabene.brown \
--to=neilb@suse.de \
--cc=hch@infradead.org \
--cc=jeff.layton@primarydata.com \
--cc=linux-nfs@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.