Messages in this thread | | | Subject | Re: PATCH - Don't remove inode from hash until filesystem has deleted it. | From | David Woodhouse <> | Date | Fri, 09 May 2003 09:06:33 +0100 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |