[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:

> > 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.


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

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
More majordomo info at
Please read the FAQ at

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