[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120904154937.e39a728e.akpm@linux-foundation.org>
Date: Tue, 4 Sep 2012 15:49:37 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: yan <clouds.yan@...il.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] proc : no need to initialize proc_inode->fd in
proc_get_inode
On Mon, 3 Sep 2012 22:14:06 +0800
yan <clouds.yan@...il.com> wrote:
> It has been initialized in proc_alloc_inode.
>
> ...
I think what you mean here is that the preceding call to iget_locked()
will call alloc_inode() which will call proc_alloc_inode() which clears
pro_inode.fd.
And if iget_locked() instead found the inode via find_inode_fast(),
that inode will not have I_NEW set so this change has no effect.
Yes? Please do spell things out in this level of detail so that others
can check your logic.
> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -450,7 +450,6 @@ struct inode *proc_get_inode(struct super_block *sb, struct proc_dir_entry *de)
> return NULL;
> if (inode->i_state & I_NEW) {
> inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
> - PROC_I(inode)->fd = 0;
> PROC_I(inode)->pde = de;
>
> if (de->mode) {
I provided this changelog:
: proc_get_inode() obtains the inode via a call to iget_locked().
: iget_locked() calls alloc_inode() which will call proc_alloc_inode() which
: clears proc_inode.fd, so there is no need to clear this field in
: proc_get_inode().
:
: If iget_locked() instead found the inode via find_inode_fast(), that inode
: will not have I_NEW set so this change has no effect.
--
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