[lkml]   [2001]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4.15-pre9 breakage (inode.c)

On Sat, 24 Nov 2001, Andrea Arcangeli wrote:

> On Fri, Nov 23, 2001 at 04:22:17PM -0500, Alexander Viro wrote:
> > Sigh... Supposed fix to problems with stale inodes was completely
> > broken.
> >
> > What we need is "if we are doing last iput() on fs that is getting
> > shut, sync it and don't leave it in cache". And yes, we have a similar
> What's this "stale inode" problem? invalidate_inodes in kill_super will
> obviously get rid of all of them or we would be getting the

First of all, there is ->read_super() side of the things. If it fails
after iget() on root, we have nothing to kick inode out of cache. And
no, we can't call invalidate_inodes() here - too late for calling any

What's more, for stuff like inodes held by superblock (e.g. fs keeping
block bitmaps in a file - in that case the earliest point that _can_
do iput() on that sucker is ->put_super(); ditto for $BIGNUM similar
cases - journal, other fs structures of that kind - ACLs, etc., etc.)
we get final iput() _after_ invalidate_inodes(). And doing anything
after ->put_super() is again too late.

IOW, we can kick inode out of icache only between successful ->read_super()
and ->put_super(). Any iput() done outside of that range must go immediately
and yes, such cases are not only possible but actually exist.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.162 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site