[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120825215239.GW23464@ZenIV.linux.org.uk>
Date: Sat, 25 Aug 2012 22:52:39 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Cyrill Gorcunov <gorcunov@...nvz.org>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Alexey Dobriyan <adobriyan@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Pavel Emelyanov <xemul@...allels.com>,
James Bottomley <jbottomley@...allels.com>,
Matthew Helsley <matt.helsley@...il.com>,
aneesh.kumar@...ux.vnet.ibm.com, bfields@...ldses.org
Subject: Re: [patch 1/9] procfs: Move /proc/pid/fd[info] handling code to
fd.[ch]
On Sat, Aug 25, 2012 at 11:43:25PM +0400, Cyrill Gorcunov wrote:
> Would the patch below improve the code? Look, I've not dropped
> find_inode_number call since it's a bit unclear for me what
> would happen if !child case hit
>
> child = d_lookup(dir, &qname);
> if (!child) {
> struct dentry *new = d_alloc(dir, &qname);
> if (new) {
> child = instantiate(dir->d_inode, new, task, ptr);
> if (child)
> dput(new);
> else
> child = new;
> }
> }
>
> can we be sure that i_ino won't be zero here?
First of all, ->i_ino is not going to be zero for any procfs inode.
As for !child case, that's possible only if d_lookup() returns NULL
*and* d_alloc() fails. In that case find_inode_number() will call
d_hash_and_lookup(), which will call d_lookup(), get NULL from it and
return NULL to find_inode_number(). Which will return 0 to the
caller.
AFAICS, if find_inode_number() is called there at all, it will return 0.
IOW, this if (!ino) ino = find_inode_number(...); is a no-op.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists