Messages in this thread |  | | Date | Sat, 24 Nov 2001 01:04:48 -0500 (EST) | From | Alexander Viro <> | Subject | Re: 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 methods.
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 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/
|  |