The patch titled
fix swapoff breakage; however...
has been removed from the -mm tree. Its filename was
memory-controller-memory-accounting-v7-fix-swapoff-breakage-however.patch
This patch was dropped because it was folded into memory-controller-memory-accounting-v7.patch
------------------------------------------------------
Subject: fix swapoff breakage; however...
From: Hugh Dickins <hugh@xxxxxxxxxxx>
rc4-mm1's memory-controller-memory-accounting-v7.patch broke swapoff:
it extended unuse_pte_range's boolean "found" return code to allow an
error return too; but ended up returning found (1) as an error.
Replace that by success (0) before it gets to the upper level.
More fundamentally, it looks like any cgroup brought over its limit in
unuse_pte will abort swapoff: that doesn't doesn't seem "contained" to me.
Maybe unuse_pte should just let cgroups go over their limits without
error? Or swap should be counted along with RSS? Needs reconsideration.
Signed-off-by: Hugh Dickins <hugh@xxxxxxxxxxx>
Cc: Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/swapfile.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/swapfile.c~memory-controller-memory-accounting-v7-fix-swapoff-breakage-however mm/swapfile.c
--- a/mm/swapfile.c~memory-controller-memory-accounting-v7-fix-swapoff-breakage-however
+++ a/mm/swapfile.c
@@ -642,7 +642,7 @@ static int unuse_mm(struct mm_struct *mm
break;
}
up_read(&mm->mmap_sem);
- return ret;
+ return (ret < 0)? ret: 0;
}
/*
_
Patches currently in -mm which might be from hugh@xxxxxxxxxxx are
origin.patch
exportfs-add-fid-type.patch
exportfs-add-new-methods.patch
shmem-new-export-ops.patch
exportfs-remove-old-methods.patch
exportfs-make-struct-export_operations-const.patch
exportfs-update-documentation.patch
memory-controller-memory-accounting-v7.patch
memory-controller-memory-accounting-v7-fix-swapoff-breakage-however.patch
prio_tree-debugging-patch.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
