[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:

> On Mon, 23 Oct 2000, Alexander Viro wrote:
> > 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.
> In fact, we used to allow them.
> We do want to remove it from the page cache under normal circumstances: it
> makes for much better MM behaviour (ie free pages that are truly useless).
> But I suspect that just adding a test for "page_count(page) == 1" (ie same
> as for the page cache invalidation) before freeing it should give that
> advantage, along with avoiding the problematic unlikely case...

That's fine, but I'm afraid that we'll need a bit more than that. A couple of
obvious ones:
* filemap_nopage() needs the second check for ->i_size. Upon exit.
Moreover, what is (area->vm_mm == current->mm) doing in the existing check?
* truncate() should zero the page out if it doesn't remove it from

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