[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:
> * 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);
ll_rw_block(READ, 1, &bh);

Forget about your "stage 1" and "stage 2" complications. They shouldn't

> 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.


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:45    [W:0.183 / U:3.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site