Messages in this thread |  | | Date | Mon, 23 Oct 2000 17:01:07 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: 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 cache.
- 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/
|  |