public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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