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

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.129 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site