[lkml]   [2000]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4.0-test10-pre3:Oops in mm/filemap.c:filemap_write_pa
On Mon, 23 Oct 2000, Linus Torvalds wrote:

> Al, any ideas? I have this feeling that the simplest fix is just to leave
> the race open, and make truncate_complete_page() just leave such a "racy"
> page in the page cache. It will still race, and the invalid page will
> still exist, but the end result should be harmless.

Provided that we clean it - why the hell do we want to take it out of
the pagecache? I don't see any fundamental reasons to prohibit pages
past the ->i_size being hashed. Methods _must_ check for ->i_size,
but they do it anyway. All race-prevention is based on page locks and

Yes, filemap_nopage() should check for i_size at the very end and fail if
the page became off-limits. But that's completely unrelated issue - it's
mmap semantics, not pagecache one.

The point being: we should _never_ drop ->mapping unless the page is
irrevocably going away. We can (and probably should) drop the off-limits
page as soon as ->count hits zero, but we should not do it before that.


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:41    [W:0.067 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site