Messages in this thread | | | Date | Mon, 18 Sep 2000 11:30:16 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: The INN/mmap bug |
| |
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/
| |