Re: [PATCH] VFS bugfix: two read_inode() calles withoutclear_inode() call between

[Andrew Morton]

"Artem B. Bityuckiy" <dedekind@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/