Messages in this thread | | | Date | Wed, 4 May 2005 13:04:50 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] VFS bugfix: two read_inode() calles without clear_inode() call between |
| |
"Artem B. Bityuckiy" <dedekind@infradead.org> wrote: > > Bug symptoms > ~~~~~~~~~~~~ > For the same inode VFS calls read_inode() twice and doesn't call > clear_inode() between the two read_inode() invocations. > > Bug description > ~~~~~~~~~~~~~~~ > Suppose we have an inode which has zero reference count but is still in > the inode cache. Suppose kswapd invokes shrink_icache_memory() to free > some RAM. In prune_icache() inodes are removed from i_hash. prune_icache > () is then going to call clear_inode(), but drops the inode_lock > spinlock before this. If in this moment another task calls iget() for an > inode which was just removed from i_hash by prune_icache(), then iget() > invokes read_inode() for this inode, because it is *already removed* > from i_hash.
This sounds more like a bug in the iget() caller to me.
Question is: if the inode has zero refcount and is unhashed then how did the caller get its sticky paws onto the inode* in the first place?
If the caller had saved a copy of the inode* in local storage then the caller should have taken a ref against the inode.
If the caller had just looked up the inode via hastable lookup via iget_whatever() then again the caller will have a ref on the inode.
So. Please tell us more about how the caller got into this situation. - 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/
| |