On Sat, 24 Nov 2001, Andrea Arcangeli wrote:
> > 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.
>
> why should you call any method, the ->read_super just make sure if it
> fails you can safely get rid of the logical struct inode. I don't see
> any problem in solving this case without special iput cases.
RTFS.
Suppose ->read_super() fails to allocate root dentry. It already has inode
of root directory in cache. It does iput() and returns.
Fine. Now we have an inode in cache. Superblock gets freed. See what
will happen next?
Right, after a while memory pressure will shrink icache. That will call
clear_inode() on our inode, followed by destroy_inode().
And clear_inode() will call inode->i_sb->s_op->clear_inode(). Oops...
That problem exists for almost every filesystem in the tree. Had been there
for quite a while.
As for the invalidate_inodes() after ->put_super() - check what 2.4.15 does
_before_ ->put_super(). All this stuff is not about inodes that need to
be written out after something that ->put_super() had done - I agree that
it's ->put_super() headache. It's about inodes that stay in icache for too
long.
Again, whenever struct inode is freed, we call ->i_sb->s_op->clear_inode()
and we'd better do that while relevant data structures are guaranteed to
be alive.
-
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/
This archive was generated by hypermail 2b29 : Fri Nov 30 2001 - 21:00:16 EST