Messages in this thread | | | Date | Mon, 23 Oct 2000 17:31:19 -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: > > > > 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. > > Nope, that just makes the race window smaller. We should check for i_size > after we've gotten the page table lock and just before actually entering > the page into the page tables. Otherwise we'll still race on SMP (a _very_ > hard window to get into, admittedly).
Umm... I would probably remove Uptodate upon truncate() and check _that_ in the place you've mentioned.
> So how about this truncate_complete_page() implementation: > > /* > * Try to get rid of a page.. Clear it if it fails > * for some reason. The page must be locked upon calling > * this function. > * > * We remove the page from the page cache _after_ we have > * destroyed all buffer-cache references to it. Otherwise some > * other process might think this inode page is not in the > * page cache and creates a buffer-cache alias to it causing > * all sorts of fun problems ... > */ > static inline void truncate_complete_page(struct page *page) > { > /* Try to get rid of buffers */ > if (page->buffers) > block_flushpage(page, 0); > > spin_lock(&pagecache_lock); > spin_lock(&pagemap_lru_lock); > > if (page_count(page) != 1) { > memclear_highpage_flush(page, 0, PAGE_CACHE_SIZE); > } else { > ClearPageDirty(page); ClearPageUptodate(page);
How about that?
> __lru_cache_del(page); > __remove_inode_page(page); > page_cache_release(page); > } > spin_unlock(&pagemap_lru_lock); > spin_unlock(&pagecache_lock); > } > > we should probably special-case the "block_flushpage()" failed case, but > the above should do reasonable things with it (because page_count() will > be > 1 due to buffers).
- 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/
| |