[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.113 / U:1.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site