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

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.081 / U:2.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site