public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
	Alexander Viro <viro@math.psu.edu>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alexander Viro <aviro@redhat.com>,
	Andrew Morton <andrewm@uow.edu.au>, Alan Cox <alan@redhat.com>,
	Christoph Rohland <cr@sap.com>,
	Rik van Riel <riel@conectiva.com.br>,
	MOLNAR Ingo <mingo@chiara.elte.hu>
Subject: Re: test12-pre5
Date: Tue, 5 Dec 2000 18:50:30 +0000	[thread overview]
Message-ID: <20001205185030.H10663@redhat.com> (raw)
In-Reply-To: <20001205170950.D10663@redhat.com> <Pine.LNX.4.21.0012050930170.18170-100000@dual.transmeta.com>
In-Reply-To: <Pine.LNX.4.21.0012050930170.18170-100000@dual.transmeta.com>; from torvalds@transmeta.com on Tue, Dec 05, 2000 at 09:48:51AM -0800

Hi,

On Tue, Dec 05, 2000 at 09:48:51AM -0800, Linus Torvalds wrote:
> 
> On Tue, 5 Dec 2000, Stephen C. Tweedie wrote:
> > 
> > That is still buggy.  We MUST NOT invalidate the inode buffers unless
> > i_nlink == 0, because otherwise a subsequent open() and fsync() will
> > have forgotten what buffers are dirty, and hence will fail to
> > synchronise properly with the disk.
> 
> Are you all on drugs?
> 
> Look at where clear_inode() is called. It's called by
> ext2_delete_inode(). It's not called by close(). Never has, never will.

It is also called during prune_icache().  Yes, I know that the
CAN_UNUSE() macro should make sure we never try to do this on a
count==0 inode which still has dirty buffers, but I'd feel happier if
we had the safety net to guard against any callers ever doing a
clear_inode while we have dirty buffers around.

We have two completely different paths to clear_inode() here: one in
which there had better not be any dirty buffers or we've got a data
corrupter on our hands, and a second in which dirty buffers are
irrelevant because we're doing a delete.

That's the problem --- doing the invalidate in clear_inode() feels
like the wrong place to do it, because our treatment of the dirty
buffers list differs depending on the caller.  I'd be much happer with
the delete case doing the invalidate, and leave clear_inode BUG()ing
if there are any dirty buffers left, and that's basically what the
test with i_nlink==0 did.

> So I repeat: are there known bugs in this area left in pre5? And with
> "bugs", I don't mean fever-induced rants like the above (*).

No, I don't think so.

Cheers,
 Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2000-12-05 19:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-05  3:20 test12-pre5 Linus Torvalds
2000-12-05  3:42 ` test12-pre5 Alexander Viro
2000-12-05  4:00   ` test12-pre5 Linus Torvalds
2000-12-05  4:25     ` test12-pre5 Alexander Viro
2000-12-05 17:09     ` test12-pre5 Stephen C. Tweedie
2000-12-05 17:28       ` test12-pre5 Alexander Viro
2000-12-05 17:48       ` test12-pre5 Linus Torvalds
2000-12-05 18:14         ` test12-pre5 Alexander Viro
2000-12-05 18:33           ` test12-pre5 Linus Torvalds
2000-12-05 18:59             ` test12-pre5 Alexander Viro
2000-12-05 19:48               ` test12-pre5 Linus Torvalds
2000-12-05 20:17                 ` test12-pre5 Alexander Viro
2000-12-05 23:15                   ` test12-pre5 Stephen C. Tweedie
2000-12-05 18:50         ` Stephen C. Tweedie [this message]
2000-12-05  5:30 ` test12-pre5 Mohammad A. Haque
2000-12-05  7:51 ` test12-pre5 Andrew Morton
2000-12-05 15:48 ` test12-pre5 Daniel Phillips
2000-12-05 23:25 ` smbfs writepage & struct file Urban Widmark
2000-12-05 23:57   ` Linus Torvalds
2000-12-06 10:05     ` Trond Myklebust
2000-12-10 13:43     ` Urban Widmark
2000-12-06 13:18 ` test12-pre5 Panu Matilainen
     [not found] <00120522275601.09076@gimli>
2000-12-05 21:58 ` test12-pre5 Linus Torvalds

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=20001205185030.H10663@redhat.com \
    --to=sct@redhat.com \
    --cc=alan@redhat.com \
    --cc=andrewm@uow.edu.au \
    --cc=aviro@redhat.com \
    --cc=cr@sap.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@chiara.elte.hu \
    --cc=riel@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