From: Nick Piggin Basically, resier4 does not present a good reason why pagecache should be dropped here. Basically the exact same operations are performed by releasepage callers (reclaim or truncate). If there is some atomicity problem, the code removed here wouldn't solve it anyway. And unless reiser4 performs some of its own special synchronisation, I can't see how it gets the pagecache removal sequence right for the reclaim case (ie. careful checks of page_count and PageDirty under tree_lock). Cc: Signed-off-by: Andrew Morton --- fs/reiser4/as_ops.c | 13 ------------- 1 files changed, 13 deletions(-) diff -puN fs/reiser4/as_ops.c~reiser4-releasepage-fix fs/reiser4/as_ops.c --- devel/fs/reiser4/as_ops.c~reiser4-releasepage-fix 2006-04-16 17:25:43.000000000 -0700 +++ devel-akpm/fs/reiser4/as_ops.c 2006-04-16 17:25:43.000000000 -0700 @@ -359,11 +359,6 @@ int reiser4_releasepage(struct page *pag assert("reiser4-4", page->mapping != NULL); assert("reiser4-5", page->mapping->host != NULL); - /* is_page_cache_freeable() check - (mapping + private + page_cache_get() by shrink_cache()) */ - if (page_count(page) > 3) - return 0; - if (PageDirty(page)) return 0; @@ -386,14 +381,6 @@ int reiser4_releasepage(struct page *pag /* we are under memory pressure so release jnode also. */ jput(node); - write_lock_irq(&mapping->tree_lock); - /* shrink_list() + radix-tree */ - if (page_count(page) == 2) { - __remove_from_page_cache(page); - atomic_dec(&page->_count); - } - write_unlock_irq(&mapping->tree_lock); - return 1; } else { spin_unlock(&(node->load)); _