From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [patch]anon_inodes.c: fix error check in anon_inode_getfd
Date: Thu, 27 Sep 2007 11:20:36 -0700
Message-ID: <20070927112036.06512479.akpm@linux-foundation.org>
References: <3d0408630709261930l730f5081n2391b236dd0efb71@mail.gmail.com>
	<20070926205957.54f49465.akpm@linux-foundation.org>
	<Pine.LNX.4.64.0709270938590.763@alien.or.mcafeemobile.com>
	<Pine.LNX.4.64.0709270953370.763@alien.or.mcafeemobile.com>
	<20070927104044.b12c1072.akpm@linux-foundation.org>
	<Pine.LNX.4.64.0709271050550.763@alien.or.mcafeemobile.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Yan Zheng <yanzheng@21cn.com>, linux-fsdevel@vger.kernel.org
To: Davide Libenzi <davidel@xmailserver.org>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from smtp2.linux-foundation.org ([207.189.120.14]:45218 "EHLO
	smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1753708AbXI0SUo (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 27 Sep 2007 14:20:44 -0400
In-Reply-To: <Pine.LNX.4.64.0709271050550.763@alien.or.mcafeemobile.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Thu, 27 Sep 2007 10:56:09 -0700 (PDT) Davide Libenzi <davidel@xmailserver.org> wrote:

> Open coded atomic_inc()? Hmm, dunno...

box:/usr/src/25> grep 'atomic_inc.*->i_count' */*.c
fs/block_dev.c:         atomic_inc(&bdev->bd_inode->i_count);
fs/block_dev.c:                 atomic_inc(&bdev->bd_inode->i_count);
fs/inode.c:             atomic_inc(&inode->i_count);
fs/inode.c:     atomic_inc(&inode->i_count);
fs/libfs.c:     atomic_inc(&inode->i_count);
fs/namei.c:                     atomic_inc(&inode->i_count);
ipc/mqueue.c:           atomic_inc(&inode->i_count);
kernel/futex.c:                 atomic_inc(&key->shared.inode->i_count);
mm/shmem.c:     atomic_inc(&inode->i_count);    /* New dentry reference */

The refcount on that inode is never zero *by design*.  So all we'd be doing
here is relying upon our existing design, so I think it'd be an OK thing to do. 
With appropriate code comments, of course.