Messages in this thread |  | | Date | Sun, 17 Sep 2000 23:23:18 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: The INN/mmap bug |
| |
On Sun, 17 Sep 2000, Linus Torvalds wrote:
> Hmm.. Ok, I see what you're saying. And I looked at the diff the wrong way > around - we _lost_ two articles rather than getting two new ones. > > However, what's wrong with the block_write_full_page() logic? Your patch > looks fine to me, but so does the old logic, I have to admit. > > Sure, __block_prepare_write() does the "optimize away reads" stuff, but > this all can only happen for pages that are up-to-date, so that shouldn't > matter. __block_commit_write() will certainly mark the buffers dirty, so I > don't see how the data would get lost anywhere. > > I bet your patch fixes the corruption, but I want to understand _why_. > Call me dense, but __block_commit_write() seems to do everything we want > done.. > > I wonder if we have some cache aliasing problem somewhere. Or what's the > bug I overlooked?
Ugh. OK, first of all, patch is _not_ correct. Doesn't zero out the end of partial block. <note to myself: no patches before the first cup of coffee>
We know that ->writepage() is called and we know that data doesn't get to the disk. How can it happen? If we can... Oh, fsck. Linus, we could very well lose the buffers since the moment when page had been read. See what happens? We recreate the buffer ring for the page and it's nowhere near "everything uptodate" state.
So yes, reading the buffers is the problem. I'll fix the zero-out part of that and send the corrected variant. From my reading of __block_write_full_page() it looks like we are OK wrt assumptions about the bh state there, but we may need to check other places where we use prepare_write().
- 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/
|  |