Messages in this thread |  | | Date | Mon, 18 Sep 2000 13:10:10 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: The INN/mmap bug |
| |
On Mon, 18 Sep 2000, Alexander Viro wrote: > > > > 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. > > Erm...
No, but that's just because you _think_ about the problem the wrong way around.
If you think about it like the above, it's not a "stage" at all. It's just part of getting the buffer to be up-to-date.
Very logical, very simple, no "fscking mess" at all.
That's my argument. You're trying to make it a problem. It's not. It's something new with the page cache, yes - the fact that the page cache drives the logic means that the buffer "uptodate" logic is different, but if you think about it some, you'll realize that that's actually just a natural outgrowth of the fact that the buffer cache is slaved to the page cache these days.
It's not a "stage 2". It's a basic fact of life - we don't care _how_ the page got to be up-to-date, because for all we know there are other ways to get it to be up-to-date than your "stage 1".
For example, a recvfile() implementation could mark the page up-to-date by virtue of getting the information off the network. No "stage 1" or "stage 2" there at all: the make_buffer_uptodate() logic does _not_ mean that we lost the buffers from "stage 1", it might equally well mean that we got the page up-to-date through some other means.
Just change how you think about the problem, and suddenly it's not a mess, it's a design.
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/
|  |