The patch titled
reiser4 releasepage fix
has been removed from the -mm tree. Its filename is
reiser4-releasepage-fix.patch
This patch was probably dropped from -mm because
it has now been merged into a subsystem tree or
into Linus's tree, or because it was folded into
its parent patch in the -mm tree.
------------------------------------------------------
Subject: reiser4 releasepage fix
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
mm-vm_bug_on.patch
mm-introduce-remap_vmalloc_range.patch
mm-introduce-remap_vmalloc_range-tidy.patch
radix-tree-direct-data.patch
radix-tree-small.patch
buglet-in-radix_tree_tag_set.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
