Re: PATCH - Don't remove inode from hash until filesystem has deleted it.

[David Woodhouse <dwmw2@infradead.org>]

On Thu, 2003-05-08 at 02:44, Neil Brown wrote:
> Don't remove inode from hash until filesystem has deleted it.
> 
> There is a small race with knfsd using iget to get an inode
> that is currently being deleted.  This is because it is removed
> from the hash table *before* the filesystem gets to delete it.
> If nfsd does an iget in this window it will cause a read_inode which
> will return an apparently valid inode.  However that inode will
> shortly be deleted from disc without knfsd noticing... until
> it is too late.

JFFS2 suffers similarly from the VFS simultaneously calling read_inode()
and clear_inode() for the same inode, since it uses iget() internally
for garbage collection. Since deletion is a slow operation which
involves marking nodes obsolete on the medium, it's nice and easy to hit
the race and have jffs2_read_inode() start walking the list of nodes
belonging to a certain inode at the same time as jffs2_clear_inode() is
walking the same list freeing them all :)

I've added locking to prevent this from happening in that particular
case, by suspending garbage collection during jffs2_clear_inode(), but
that's undesirable and anyway, the problem still exists when a JFFS2
file system is exported by nfsd, if nfsd attempts to open the inode
while it's being deleted.

Your patch should solve that too -- looks sane to me.

-- 
dwmw2