Re: 2.4.15-pre9 breakage (inode.c)

[Andrea Arcangeli <andrea@suse.de>]

On Sat, Nov 24, 2001 at 03:05:02AM -0500, Alexander Viro wrote:
> 
> 
> On Sat, 24 Nov 2001, Andrea Arcangeli wrote:
> 
> > > Notice that it fixes _all_ problems with stale inodes, with only one rule
> > > for fs code - "don't call iput() when ->clear_inode() doesn't work".  Your
> > > variant requires funnier things - "if at some point ->clear_inode()
> > > may stop working make sure to call invalidate_inodes()" in addition to
> > > the rule above.
> > 
> > the rule I add is "if ->clear_inode is really needed, just don't clear
> > s_op before returning null from read_super" and that requirement looks
> > fine.
> 
> It's not that simple.  You may need the per-superblock data structures for
> ->clear_inode() to work.
> 
> In any case, it _is_ additional rule for no good reason.  "inode may stay
> in icache after iput() only when fs is up and running" is a warranty that
> is trivial to provide and that removes a source of hard-to-debug screwups
> in fs code.

I don't think it's harder to debug, you need the per-superblock data
structures for ->clear_inode() also if you try to ->clear_inode in iput,
and I cannot see any valid reason for which the fs would be allowed to
screwup the superblock before returning from read_inode. As soon as you
call iget the superblock must be sane and there's no point in screwing
it up afterwards.

Andrea