The patch titled
reiser4 releasepage fix
has been added to the -mm tree. Its filename is
reiser4-releasepage-fix.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
From: Nick Piggin <npiggin@xxxxxxx>
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: <reiserfs-dev@xxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
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));
_
Patches currently in -mm which might be from npiggin@xxxxxxx are
origin.patch
mm-vm_bug_on.patch
reiser4-releasepage-fix.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
