On Sat, Nov 24, 2001 at 02:30:15AM -0500, Alexander Viro wrote:
>
>
> On Sat, 24 Nov 2001, Andrea Arcangeli wrote:
>
> > if the method or the s_op isn't defined it will do nothing, if it is
> > defined it'd better do something not wrong because the fs just did an
> > iget within read_super. I don't see obvious troubles and the above looks
> > better than making iput more complex (and nitpicking slower 8).
>
> 2.4.15-pre8:
>
> if (!list_empty(&inode->i_hash)) {
> FOO
> return;
> } else {
> BAR
> }
>
> 2.4.15+patch:
>
> if (!list_empty(&inode->i_hash)) {
> FOO
> if (!sb || sb->s_flags & MS_ACTIVE)
> return;
> write_inode_now(inode, 1);
> spin_lock(&inode_lock);
> inodes_stat.nr_unused--;
> list_del_init(&inode->i_hash);
> }
> BAR
>
> 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.
>
> Frankly, I'd prefer fix that provides less possibilities for fsckup
> in fs code and requires less analysis.
I think right fix is invalidate_inodes() in read_super fail path so I
think it worth the short analysis, and that fail path was just buggy, so
it shouldn't get worse at least :).
Andrea
-
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