From: "Stephen C. Tweedie" <sct@redhat.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
Stephen Tweedie <sct@redhat.com>
Subject: Re: [PATCH] inode dirty blocks Re: test12-pre4
Date: Mon, 4 Dec 2000 18:16:21 +0000 [thread overview]
Message-ID: <20001204181621.E8700@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10012031828170.22914-100000@penguin.transmeta.com> <Pine.GSO.4.21.0012040054400.5055-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0012040054400.5055-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Mon, Dec 04, 2000 at 01:01:36AM -0500
On Mon, Dec 04, 2000 at 01:01:36AM -0500, Alexander Viro wrote:
>
> It doesn't solve the problem. If you unlink a file with dirty metadata
> you have a nice chance to hit the BUG() in inode.c:83. I hope that patch
> below closes all remaining holes. See analysis in previous posting
> (basically, bforget() is not enough when we free the block; bh should
> be removed from the inode's list regardless of the ->b_count).
Agreed. However, is there any reason to have this as a separate
function? bforget() should _always_ remove the buffer from any inode
queue. You can make that operation conditional on (bh->b_inode !=
NULL) if you want to avoid taking the lru lock unnecessarily.
--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/
next prev parent reply other threads:[~2000-12-04 18:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-04 2:29 test12-pre4 Linus Torvalds
2000-12-04 3:57 ` test12-pre4 Mohammad A. Haque
2000-12-04 8:03 ` test12-pre4 Jeff Garzik
2000-12-04 12:25 ` test12-pre4 Alan Cox
2000-12-04 12:21 ` test12-pre4 Alan Cox
2000-12-04 20:22 ` test12-pre4 Nikhil Goel
2000-12-04 6:01 ` [PATCH] inode dirty blocks test12-pre4 Alexander Viro
2000-12-04 13:25 ` Andrew Morton
2000-12-04 13:49 ` [PATCH] inode dirty blocks Alexander Viro
2000-12-05 1:47 ` Andrew Morton
2000-12-05 2:41 ` Linus Torvalds
2000-12-05 3:31 ` Alexander Viro
2000-12-05 3:52 ` Linus Torvalds
2000-12-05 4:19 ` Alexander Viro
2000-12-05 2:49 ` Mohammad A. Haque
2000-12-05 4:15 ` Peter Samuelson
2000-12-04 18:16 ` Stephen C. Tweedie [this message]
2000-12-04 19:54 ` [PATCH] inode dirty blocks Re: test12-pre4 Alexander Viro
2000-12-05 20:35 ` Andrew Morton
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=20001204181621.E8700@redhat.com \
--to=sct@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--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.