From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoph Hellwig <hch@infradead.org>
Subject: Re: iget4/read_inode2 race in get_new_inode
Date: Mon, 29 Apr 2002 20:51:13 +0100
Sender: linux-fsdevel-owner@vger.kernel.org
Message-ID: <20020429205113.A31052@infradead.org>
References: <20020429164844.GA4846@ravel.coda.cs.cmu.edu> <Pine.GSO.4.21.0204291344070.2918-100000@weyl.math.psu.edu> <5.1.0.14.2.20020429201020.04a2eec0@pop.cus.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Alexander Viro <viro@math.psu.edu>,
	Jan Harkes <jaharkes@cs.cmu.edu>, linux-fsdevel@vger.kernel.org
Return-path: <linux-fsdevel-owner@vger.kernel.org>
To: Anton Altaparmakov <aia21@cantab.net>
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20020429201020.04a2eec0@pop.cus.cam.ac.uk>; from aia21@cantab.net on Mon, Apr 29, 2002 at 08:34:00PM +0100
List-Id: linux-fsdevel.vger.kernel.org

On Mon, Apr 29, 2002 at 08:34:00PM +0100, Anton Altaparmakov wrote:
> 
> - Replace iget4() with iget5() with an additional argument: a callback to 
> initialize a locked inode in order to kill the race condition Jan found.
> 
> struct inode *iget5(sb, ino, find_actor, init_locked_actor, void *opaque);
> 
> - Let get_new_inode() call init_locked_actor before dropping the 
> inode_lock. It then calls ->read_inode as usual.

Don't do this - rather use the XFS-style icreate() plus per-filesystem
exclusion.  The VFS shouldn't have to worry about this kind of problems,
especially with such an ugly API.

> struct inode *fs_iget(sb, ino, find_actor, init_locked_actor, opaque, 
> fs_read_inode)
> {
>          inode = iget5(sb, ino, find_actor, init_locked_actor, opaque);
>          if (inode has I_NEW set) {
>                  fs_read_inode(inode);
>                  unlock_new_inode(inode);
>          }
>          return inode;
> }

I already though about this alot (as generic_iget()), but I wonder whether
it is really worth the effort or whether filesystems should just duplicate
that 5 lines.