From: Andrea Arcangeli <andrea@suse.de>
To: Alexander Viro <viro@math.psu.edu>
Cc: Linus Torvalds <torvalds@transmeta.com>,
linux-kernel@vger.kernel.org,
Marcelo Tosatti <marcelo@conectiva.com.br>
Subject: Re: 2.4.15-pre9 breakage (inode.c)
Date: Sat, 24 Nov 2001 10:38:55 +0100 [thread overview]
Message-ID: <20011124103854.I1419@athlon.random> (raw)
In-Reply-To: <20011124092126.D1419@athlon.random> <Pine.GSO.4.21.0111240321470.4000-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0111240321470.4000-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Sat, Nov 24, 2001 at 03:38:07AM -0500
On Sat, Nov 24, 2001 at 03:38:07AM -0500, Alexander Viro wrote:
>
>
> On Sat, 24 Nov 2001, Andrea Arcangeli wrote:
>
> > 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.
>
> Sigh...
>
> set per-sb structures
> ...
> iget()
> ...
> sanity checks
> ...
> normal return
> sanity_checks_failed:
> iput()
> ...
> free per-sb structures
> ...
> return NULL;
>
> Looks sane, doesn't it? And that's pretty much the only way to go if
yes, it's definitely sane.
> we allocate that stuff dynamically. With your variant we _must_ call
> invalidate_inodes() here to force eviction from icache. What's more,
> not calling it will screw up non-deterministically - it will survive
> if inode gets evicted in the right interval and produce whatever damage
> it's going to produce if eviction happens too late.
>
> Again, what we really want here is "don't keep inodes dropped during
> ->read_super() or ->put_super() in icache". You propose to stick
> invalidate_inodes() in a bunch of places so that it would kill these
> inodes before it's too late. For some filesystems it would be
correct.
> covered by ones you add in fs/super.c, for other it would need
> explicit calls, required positions may depend on the fs internals
> and change with them... What I propose is "don't wait, kill them
> immediately and forget about the whole thing".
I don't like bloating iput with code just needed for backwards
compatibility with buggy code and for a non common case (infact it's not
even backwards compatibiltiy, if something it would be instead bugwards
compatibility 8).
OTOH I see the iget/iput semantics within the read_super/put_super (not
the code!) would be cleaner your way, so we don't even need to document
that if a per-sb ->clear_inode needs to access any per-sb special
structures, invalidate_inodes(sb) must be called before freeing the
per-sb structures [always ignoring any possible flush] (plus the fact
sb->s_op must not be clobbered before returning from read_super, so that
the vfs can see the s_op->clear_inode, but nobody should do that
anyways). btw, even your way we should still make sure nobody is
calling iput after freeing the per-sb structures :).
In practice I had a very short look at all the ->clear_inode implemented
and none seems to need the special per-sb structures, so I think also my
patch is just fine for current tree 2.4. (I guess somebody should check
xfs and jfs too)
I think long term (2.5) the right way is to replace all the iput in the
slow fail paths with a iput_not_mounted, that will avoid both the iput
clobbering and the MS_ACTIVE tracking. The differentiation should be
quite self documenting (so people will taste that this iput_not_mounted
is kind of raw thing that will flush + ->clear_inode and destroy the
inode synchronously, so ->clear_inode has to work while recalling
iput_not_mounted). It should be very easy to identify the iputs in the
read_super/put_super paths to replace them with the iput_not_mounted (at
least for the normal fs like ext2/minix etc..).
Andrea
next prev parent reply other threads:[~2001-11-24 9:39 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-23 21:22 2.4.15-pre9 breakage (inode.c) Alexander Viro
2001-11-23 21:42 ` Jeff Merkey
2001-11-23 21:51 ` [PATCH][CFT] " Alexander Viro
2001-11-23 22:06 ` Alexander Viro
2001-11-23 22:34 ` Russell King
2001-11-23 22:35 ` Phil Sorber
2001-11-23 22:49 ` Alexander Viro
2001-11-23 23:05 ` Andreas Dilger
2001-11-23 23:35 ` Russell King
2001-11-24 1:48 ` Linus Torvalds
2001-11-24 5:47 ` Andrea Arcangeli
2001-11-24 5:55 ` Linus Torvalds
2001-11-24 6:08 ` Alexander Viro
2001-11-24 6:26 ` Andrea Arcangeli
2001-11-24 6:31 ` Alexander Viro
2001-11-24 6:37 ` Alexander Viro
2001-11-24 6:50 ` Andrea Arcangeli
2001-11-24 6:58 ` Alexander Viro
2001-11-24 7:01 ` Andrea Arcangeli
2001-11-24 7:06 ` Alexander Viro
2001-11-24 7:12 ` Andrea Arcangeli
2001-11-24 7:30 ` Alexander Viro
2001-11-24 7:44 ` Andrea Arcangeli
2001-11-24 8:05 ` Alexander Viro
2001-11-24 8:21 ` Andrea Arcangeli
2001-11-24 8:38 ` Alexander Viro
2001-11-24 9:38 ` Andrea Arcangeli [this message]
2001-11-24 9:56 ` Alexander Viro
2001-11-24 10:25 ` Andrea Arcangeli
2001-11-24 6:44 ` Andrea Arcangeli
2001-11-24 6:51 ` Alexander Viro
2001-11-24 9:00 ` Russell King
2001-11-24 10:20 ` Christian Bornträger
2001-11-24 6:04 ` Alexander Viro
2001-11-24 6:20 ` Andrea Arcangeli
2001-11-24 6:29 ` Alexander Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011124103854.I1419@athlon.random \
--to=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox