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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.