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