On Mon, 18 Sep 2000, Alexander Viro wrote:
> * we have several bh state components and the thing is a big,
> fscking mess. If we look at the areas outside of the page lock we have:
It's not a mess at all.
I don't see why you call things "first stage" etc. It's perfectly
straightforward. There are two bits that matter:
- buffer uptodate
- buffer mapped.
And the state is very clear and unambiguous:
Mapped, Uptodate: regular block
!Mapped, Uptodate: hole of zeroes
Mapped, !Uptodate: unread
!Mapped, !Uptodate: "pending map"
No "several states" at all.
It so happens that we forgot an important part of the "read a buffer"
equation. The "read a buffer" function is NOT just
static int make_buffer_uptodate(struct buffer_head * bh)
{
ll_rw_block(READ, 1, &bh);
}
but should instead be
static int make_buffer_uptodate(struct page *page, struct buffer_head * bh)
{
if (Page_Uptodate(page)) {
set_bit(BH_Uptodate, &bh->b_state);
return;
}
ll_rw_block(READ, 1, &bh);
}
Forget about your "stage 1" and "stage 2" complications. They shouldn't
exist.
> 1st stage, uptodate, !mapped hole. Contents is all-zeroes. It may also
> be a result of failed attempt to map - we
> have no way to tell.
The "uptodate !mapped" case is entirely clear: it's a hole. No ifs, no
buts, no nothing.
If a map() failed, that map() will have returned an error, and if
something turns the buffer uptodate that's a BUG.
Linus
-
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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:18 EST