Memory failure on a KSM page currently oopses on its NULL anon_vma in
page_lock_anon_vma(): that may not be much worse than the consequence
of ignoring it, but it is better to be consistent with how ZERO_PAGE
and hugetlb pages and other awkward cases are treated. Just skip it.
Signed-off-by: Hugh Dickins <[email protected]>
---
We could fix it for 2.6.32 at the KSM end, by putting a dummy anon_vma
pointer in there; but that would get harder next time, when KSM will
put a pointer to something else there (and I'm not currently planning
to do any work to open that up to memory_failure). So I would prefer
this simple PageKsm test, until the other exceptions are handled.
mm/memory-failure.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- 2.6.32-rc4/mm/memory-failure.c 2009-09-28 00:28:41.000000000 +0100
+++ linux/mm/memory-failure.c 2009-10-13 14:09:12.000000000 +0100
@@ -35,6 +35,7 @@
#include <linux/mm.h>
#include <linux/page-flags.h>
#include <linux/sched.h>
+#include <linux/ksm.h>
#include <linux/rmap.h>
#include <linux/pagemap.h>
#include <linux/swap.h>
@@ -661,7 +662,7 @@ static void hwpoison_user_mappings(struc
int i;
int kill = 1;
- if (PageReserved(p) || PageCompound(p) || PageSlab(p))
+ if (PageReserved(p) || PageCompound(p) || PageSlab(p) || PageKsm(p))
return;
if (!PageLRU(p))
On Tue, Oct 13, 2009 at 03:02:11PM +0100, Hugh Dickins wrote:
> Memory failure on a KSM page currently oopses on its NULL anon_vma in
> page_lock_anon_vma(): that may not be much worse than the consequence
> of ignoring it, but it is better to be consistent with how ZERO_PAGE
> and hugetlb pages and other awkward cases are treated. Just skip it.
Thanks, Hugh. I'm curious: did this come out of code review or
did you actually run into that?
-Andi
--
[email protected] -- Speaking for myself only.
On Tue, 13 Oct 2009, Andi Kleen wrote:
> On Tue, Oct 13, 2009 at 03:02:11PM +0100, Hugh Dickins wrote:
> > Memory failure on a KSM page currently oopses on its NULL anon_vma in
> > page_lock_anon_vma(): that may not be much worse than the consequence
> > of ignoring it, but it is better to be consistent with how ZERO_PAGE
> > and hugetlb pages and other awkward cases are treated. Just skip it.
>
> Thanks, Hugh. I'm curious: did this come out of code review or
> did you actually run into that?
Just out of code review: well, that's too fancy a name for it, I merely
remembered that I hadn't looked at ksm/hwpoison interoperabilty, so did
so just now. After looking at the code, I did then try MADV_HWPOISON on
a MADV_MERGEABLE area, to check that the problem and the fix were real.
Hugh