lkml.org 
[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: The INN/mmap bug


On Sun, 17 Sep 2000, Linus Torvalds wrote:

> Yeah. See my other mail - I don't think the patch is needed at all,
> although I'm convinced that it would actually hide the problem for the
> particular case of INN (zeroing out the partial block is not an issue
> there, as truncate will have done it - it's really only protection against
> badly behaved software and shouldn't matter to any "regular" use).

True, but that way we also get the consistent rules wrt. async/sync.

> > 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.
>
> Yeah. See my suggested fix in the other mail. We just must not read in
> buffers for pages that are already up-to-date.

We might as well do it in create_empty_buffers(), FWIW. Do you see any
case when it would mean extra work? I'm thinking about the following:

if (page is uptodate)
do get_block(...,0) for all buffers and mark them uptodate

in the end of buffer-ring creation. Comments?

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

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.086 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site