Re: The INN/mmap bug

From: Linus Torvalds (torvalds@transmeta.com)
Date: Mon Sep 18 2000 - 16:34:56 EST


On Mon, 18 Sep 2000, Alexander Viro wrote:
> Umm... OK. Let me put it that way:
> * uptodate pages should never become non-uptodate.

Agreed. That "ClearPageUptodate()" thing definitely looks like a bug.

> * we do multiple read requests on the same buffer.

Right now, yes. And that is a bad bug.

> * the only thing saving us from data loss is that non-uptodate
> pages never lose buffers when they have data newer than on disk (uptodate
> pages do, but they never have data _older_ than on disk). Thus we can
> afford rereading a buffer on non-uptodate page if bh was lost and never
> have to reread it on uptodate page.

Right. Basically we will drop the buffers only after they have been
written out, so normal read/write can never lose data.

It's only the case of shared mmap's that can lose data due to the stupid
"let's read it in from disk again" thing.

> * look at the explanation above and see if it looks brittle. It
> really needs to be documented

Oh, I certainly agree.

And I also agree that we should work on making the "create_page_buffers"
thing more easily used - the code duplication in the different parts of
fs/buffer.c is quite horrible. It tends to be the same kind of logic,
except it has small differences in four-five different versions.

I think it would be better to do the code part first, actually: once that
is done, a single comment above "create_page_buffers" will explain
everything that is going on..

> That's what makes me unhappy about the current situation + obvious
> fixes. It works, but the proof is... well, not pretty.

Oh, agreed. I think we should clean up the code. I looked at it yesterday,
and it didn't look all that horribly bad, but I lost interest. I don't
know if it is worth doing before 2.4.x, as the current code certainly
should work with the small changes already proposed.

                        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