linux-kernel - Re: [PATCH] hugetlb: restrict hugepage_migration_support() to x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1401413716.29324.2.camel@concordia>
Date:	Fri, 30 May 2014 11:35:16 +1000
From:	Michael Ellerman <mpe@...erman.id.au>
To:	Naoya Horiguchi <n-horiguchi@...jp.nec.com>
Cc:	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	benh@...nel.crashing.org, Tony Luck <tony.luck@...el.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	trinity@...r.kernel.org
Subject: Re: [PATCH] hugetlb: restrict hugepage_migration_support() to
 x86_64 (Re: BUG at mm/memory.c:1489!)

On Thu, 2014-05-29 at 14:34 -0400, Naoya Horiguchi wrote:
> On Thu, May 29, 2014 at 06:59:43PM +1000, Michael Ellerman wrote:
> > Applying your patch and running trinity pretty immediately results in the
> > following, which looks related (sys_move_pages() again) ?
> >
> > Unable to handle kernel paging request for data at address 0xf2000f80000000
> > Faulting instruction address: 0xc0000000001e29bc
> > cpu 0x1b: Vector: 300 (Data Access) at [c0000003c70f76f0]
> >     pc: c0000000001e29bc: .remove_migration_pte+0x9c/0x320
> >     lr: c0000000001e29b8: .remove_migration_pte+0x98/0x320
> >     sp: c0000003c70f7970
> >    msr: 8000000000009032
> >    dar: f2000f80000000
> >  dsisr: 40000000
> >   current = 0xc0000003f9045800
> >   paca    = 0xc000000001dc6c00   softe: 0        irq_happened: 0x01
> >     pid   = 3585, comm = trinity-c27
> > enter ? for help
> > [c0000003c70f7a20] c0000000001bce88 .rmap_walk+0x328/0x470
> > [c0000003c70f7ae0] c0000000001e2904 .remove_migration_ptes+0x44/0x60
> > [c0000003c70f7b80] c0000000001e4ce8 .migrate_pages+0x6d8/0xa00
> > [c0000003c70f7cc0] c0000000001e55ec .SyS_move_pages+0x5dc/0x7d0
> > [c0000003c70f7e30] c00000000000a1d8 syscall_exit+0x0/0x98
> > --- Exception: c01 (System Call) at 00003fff7b2b30a8
> > SP (3fffe09728a0) is in userspace
> > 1b:mon>
>
> Sorry for inconvenience on your testing.
 
That's fine, it's good to find bugs :)

> Hugepage migration is enabled for archs which have pmd-level hugepage
> (including ppc64,) but not tested except for x86_64.
> hugepage_migration_support() controls this so the following patch should
> help you avoid the problem, I believe.
> Could you try to test with it?

Sure. So this patch, in addition to Hugh's patch to remove the BUG_ON(), does
avoid the crash above (remove_migration_pte()).

I dropped Hugh's patch, as he has decided he doesn't like it, and added the
following hunk instead:

diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
index 3c1b968..f230a97 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -175,6 +175,12 @@ static inline int vma_migratable(struct vm_area_struct *vma)
 {
        if (vma->vm_flags & (VM_IO | VM_PFNMAP))
                return 0;
+
+#ifndef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
+       if (vma->vm_flags & VM_HUGETLB)
+               return 0;
+#endif
+
        /*
         * Migration allocates pages in the highest zone. If we cannot
         * do so then migration (at least from node to node) is not


Which seems to be what Hugh was referring to in his mail - correct me if I'm
wrong Hugh.

With your patch and the above hunk I can run trinity happily for a while,
whereas without it crashes almost immediately.

So with the above hunk you can add my tested-by.

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/