Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008

Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008

[Andrey Korolyov]

>Hi,
>
>I've seen the problem quite a few times.  Before spending more time on
>it, I'd like to have a quick check here to see if anyone ever saw the
>same problem?  Hope it is a relevant question with this mail list.
>
>
>Jul  2 11:08:21 arno-3 kernel: [ 2165.078623] BUG: unable to handle
>kernel NULL pointer dereference at 0000000000000008
>Jul  2 11:08:21 arno-3 kernel: [ 2165.078916] IP: [<ffffffff8118d0fa>]
>copy_huge_page+0x8a/0x2a0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.079128] PGD 0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.079198] Oops: 0000 [#1] SMP
>Jul  2 11:08:21 arno-3 kernel: [ 2165.079319] Modules linked in:
>ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE
>iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
>xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
>iptable_filter ip_tables x_tables kvm_intel kvm bridge stp llc ast ttm
>drm_kms_helper drm sysimgblt sysfillrect syscopyarea lp mei_me ioatdma
>ext2 parport mei shpchp dcdbas joydev mac_hid lpc_ich acpi_pad wmi
>hid_generic usbhid hid ixgbe igb dca i2c_algo_bit ahci ptp libahci
>mdio pps_core
>Jul  2 11:08:21 arno-3 kernel: [ 2165.081090] CPU: 19 PID: 3494 Comm:
>qemu-system-x86 Not tainted 3.11.0-15-generic #25~precise1-Ubuntu
>Jul  2 11:08:21 arno-3 kernel: [ 2165.081424] Hardware name: Dell Inc.
>PowerEdge C6220 II/09N44V, BIOS 2.0.3 07/03/2013
>Jul  2 11:08:21 arno-3 kernel: [ 2165.081705] task: ffff881026750000
>ti: ffff881026056000 task.ti: ffff881026056000
>Jul  2 11:08:21 arno-3 kernel: [ 2165.081973] RIP:
>0010:[<ffffffff8118d0fa>]  [<ffffffff8118d0fa>]
>copy_huge_page+0x8a/0x2a0


Hello,

sorry for possible top-posting, the same issue appears on at least
3.10 LTS series. The original thread is at
http://marc.info/?l=kvm&m=14043742300901. The necessary components for
failure to reappear are a single running kvm guest and mounted large
thp: hugepagesz=1G (seemingly the same as in initial report). With
default 2M pages everything is working well, the same for 3.18 with 1G
THP. Are there any obvious clues for the issue?

Thanks!

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008

[Andrey Korolyov]

Sorry for all the previous mess, my Claws-mailer went nuts for no reason.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008

[Marcelo Tosatti]

On Wed, Feb 04, 2015 at 08:34:04PM +0400, Andrey Korolyov wrote:
> >Hi,
> >
> >I've seen the problem quite a few times.  Before spending more time on
> >it, I'd like to have a quick check here to see if anyone ever saw the
> >same problem?  Hope it is a relevant question with this mail list.
> >
> >
> >Jul  2 11:08:21 arno-3 kernel: [ 2165.078623] BUG: unable to handle
> >kernel NULL pointer dereference at 0000000000000008
> >Jul  2 11:08:21 arno-3 kernel: [ 2165.078916] IP: [<ffffffff8118d0fa>]
> >copy_huge_page+0x8a/0x2a0
> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079128] PGD 0
> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079198] Oops: 0000 [#1] SMP
> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079319] Modules linked in:
> >ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE
> >iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
> >xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
> >iptable_filter ip_tables x_tables kvm_intel kvm bridge stp llc ast ttm
> >drm_kms_helper drm sysimgblt sysfillrect syscopyarea lp mei_me ioatdma
> >ext2 parport mei shpchp dcdbas joydev mac_hid lpc_ich acpi_pad wmi
> >hid_generic usbhid hid ixgbe igb dca i2c_algo_bit ahci ptp libahci
> >mdio pps_core
> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081090] CPU: 19 PID: 3494 Comm:
> >qemu-system-x86 Not tainted 3.11.0-15-generic #25~precise1-Ubuntu
> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081424] Hardware name: Dell Inc.
> >PowerEdge C6220 II/09N44V, BIOS 2.0.3 07/03/2013
> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081705] task: ffff881026750000
> >ti: ffff881026056000 task.ti: ffff881026056000
> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081973] RIP:
> >0010:[<ffffffff8118d0fa>]  [<ffffffff8118d0fa>]
> >copy_huge_page+0x8a/0x2a0
> 
> 
> Hello,
> 
> sorry for possible top-posting, the same issue appears on at least
> 3.10 LTS series. The original thread is at
> http://marc.info/?l=kvm&m=14043742300901.

Andrey,

I am unable to access the URL above?

> The necessary components for failure to reappear are a single running
> kvm guest and mounted large thp: hugepagesz=1G (seemingly the same as
> in initial report). With default 2M pages everything is working well,
> the same for 3.18 with 1G THP. Are there any obvious clues for the
> issue?
> 
> Thanks!



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008

[Andrey Korolyov]

On Tue, Feb 24, 2015 at 3:12 AM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
> On Wed, Feb 04, 2015 at 08:34:04PM +0400, Andrey Korolyov wrote:
>> >Hi,
>> >
>> >I've seen the problem quite a few times.  Before spending more time on
>> >it, I'd like to have a quick check here to see if anyone ever saw the
>> >same problem?  Hope it is a relevant question with this mail list.
>> >
>> >
>> >Jul  2 11:08:21 arno-3 kernel: [ 2165.078623] BUG: unable to handle
>> >kernel NULL pointer dereference at 0000000000000008
>> >Jul  2 11:08:21 arno-3 kernel: [ 2165.078916] IP: [<ffffffff8118d0fa>]
>> >copy_huge_page+0x8a/0x2a0
>> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079128] PGD 0
>> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079198] Oops: 0000 [#1] SMP
>> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079319] Modules linked in:
>> >ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE
>> >iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
>> >xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
>> >iptable_filter ip_tables x_tables kvm_intel kvm bridge stp llc ast ttm
>> >drm_kms_helper drm sysimgblt sysfillrect syscopyarea lp mei_me ioatdma
>> >ext2 parport mei shpchp dcdbas joydev mac_hid lpc_ich acpi_pad wmi
>> >hid_generic usbhid hid ixgbe igb dca i2c_algo_bit ahci ptp libahci
>> >mdio pps_core
>> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081090] CPU: 19 PID: 3494 Comm:
>> >qemu-system-x86 Not tainted 3.11.0-15-generic #25~precise1-Ubuntu
>> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081424] Hardware name: Dell Inc.
>> >PowerEdge C6220 II/09N44V, BIOS 2.0.3 07/03/2013
>> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081705] task: ffff881026750000
>> >ti: ffff881026056000 task.ti: ffff881026056000
>> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081973] RIP:
>> >0010:[<ffffffff8118d0fa>]  [<ffffffff8118d0fa>]
>> >copy_huge_page+0x8a/0x2a0
>>
>>
>> Hello,
>>
>> sorry for possible top-posting, the same issue appears on at least
>> 3.10 LTS series. The original thread is at
>> http://marc.info/?l=kvm&m=14043742300901.
>
> Andrey,
>
> I am unable to access the URL above?
>
>> The necessary components for failure to reappear are a single running
>> kvm guest and mounted large thp: hugepagesz=1G (seemingly the same as
>> in initial report). With default 2M pages everything is working well,
>> the same for 3.18 with 1G THP. Are there any obvious clues for the
>> issue?
>>
>> Thanks!
>
>

Hello,

Marcelo, sorry, I`ve missed your reply in time. The working link, for
example is http://www.spinics.net/lists/linux-mm/msg75658.html. The
reproducer is a very simple, you need 1G THP and mounted hugetlbfs.
What is interesting, if guest is backed by THP like '-object
memory-backend-file,id=mem,size=1G,mem-path=/hugepages,share=on' the
failure is less likely to occur.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008

[Hugh Dickins]

On Sat, 28 Mar 2015, Andrey Korolyov wrote:
> On Tue, Feb 24, 2015 at 3:12 AM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
> > On Wed, Feb 04, 2015 at 08:34:04PM +0400, Andrey Korolyov wrote:
> >> >Hi,
> >> >
> >> >I've seen the problem quite a few times.  Before spending more time on
> >> >it, I'd like to have a quick check here to see if anyone ever saw the
> >> >same problem?  Hope it is a relevant question with this mail list.
> >> >
> >> >
> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.078623] BUG: unable to handle
> >> >kernel NULL pointer dereference at 0000000000000008
> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.078916] IP: [<ffffffff8118d0fa>]
> >> >copy_huge_page+0x8a/0x2a0
> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079128] PGD 0
> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079198] Oops: 0000 [#1] SMP
> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079319] Modules linked in:
> >> >ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE
> >> >iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
> >> >xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
> >> >iptable_filter ip_tables x_tables kvm_intel kvm bridge stp llc ast ttm
> >> >drm_kms_helper drm sysimgblt sysfillrect syscopyarea lp mei_me ioatdma
> >> >ext2 parport mei shpchp dcdbas joydev mac_hid lpc_ich acpi_pad wmi
> >> >hid_generic usbhid hid ixgbe igb dca i2c_algo_bit ahci ptp libahci
> >> >mdio pps_core
> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081090] CPU: 19 PID: 3494 Comm:
> >> >qemu-system-x86 Not tainted 3.11.0-15-generic #25~precise1-Ubuntu
> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081424] Hardware name: Dell Inc.
> >> >PowerEdge C6220 II/09N44V, BIOS 2.0.3 07/03/2013
> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081705] task: ffff881026750000
> >> >ti: ffff881026056000 task.ti: ffff881026056000
> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081973] RIP:
> >> >0010:[<ffffffff8118d0fa>]  [<ffffffff8118d0fa>]
> >> >copy_huge_page+0x8a/0x2a0
> >>
> >>
> >> Hello,
> >>
> >> sorry for possible top-posting, the same issue appears on at least
> >> 3.10 LTS series. The original thread is at
> >> http://marc.info/?l=kvm&m=14043742300901.
> >
> > Andrey,
> >
> > I am unable to access the URL above?
> >
> >> The necessary components for failure to reappear are a single running
> >> kvm guest and mounted large thp: hugepagesz=1G (seemingly the same as
> >> in initial report). With default 2M pages everything is working well,
> >> the same for 3.18 with 1G THP. Are there any obvious clues for the
> >> issue?
> >>
> >> Thanks!
> >
> >
> 
> Hello,
> 
> Marcelo, sorry, I`ve missed your reply in time. The working link, for
> example is http://www.spinics.net/lists/linux-mm/msg75658.html. The
> reproducer is a very simple, you need 1G THP and mounted hugetlbfs.
> What is interesting, if guest is backed by THP like '-object
> memory-backend-file,id=mem,size=1G,mem-path=/hugepages,share=on' the
> failure is less likely to occur.

I think you're mistaken when you write of "1G THP": although hugetlbfs
can support 1G hugepages, we don't support that size with Transparent
Huge Pages.

But you are very appositely mistaken: copy_huge_page() used to make
the same mistake, and Dave Hansen fixed it back in v3.13, but the fix
never went to the stable trees.

Your report was on an Ubuntu "3.11.0-15" kernel: I think Ubuntu have
discontinued their 3.11-stable kernel series, but 3.10-longterm and
3.12-longterm would benefit from including this fix.  I haven't tried
patching and  building and testing it there, but it looks reasonable.

Hugh

commit 30b0a105d9f7141e4cbf72ae5511832457d89788
Author: Dave Hansen <dave.hansen@linux.intel.com>
Date:   Thu Nov 21 14:31:58 2013 -0800

    mm: thp: give transparent hugepage code a separate copy_page
    
    Right now, the migration code in migrate_page_copy() uses copy_huge_page()
    for hugetlbfs and thp pages:
    
           if (PageHuge(page) || PageTransHuge(page))
                    copy_huge_page(newpage, page);
    
    So, yay for code reuse.  But:
    
      void copy_huge_page(struct page *dst, struct page *src)
      {
            struct hstate *h = page_hstate(src);
    
    and a non-hugetlbfs page has no page_hstate().  This works 99% of the
    time because page_hstate() determines the hstate from the page order
    alone.  Since the page order of a THP page matches the default hugetlbfs
    page order, it works.
    
    But, if you change the default huge page size on the boot command-line
    (say default_hugepagesz=1G), then we might not even *have* a 2MB hstate
    so page_hstate() returns null and copy_huge_page() oopses pretty fast
    since copy_huge_page() dereferences the hstate:
    
      void copy_huge_page(struct page *dst, struct page *src)
      {
            struct hstate *h = page_hstate(src);
            if (unlikely(pages_per_huge_page(h) > MAX_ORDER_NR_PAGES)) {
      ...
    
    Mel noticed that the migration code is really the only user of these
    functions.  This moves all the copy code over to migrate.c and makes
    copy_huge_page() work for THP by checking for it explicitly.
    
    I believe the bug was introduced in commit b32967ff101a ("mm: numa: Add
    THP migration for the NUMA working set scanning fault case")
    
    [akpm@linux-foundation.org: fix coding-style and comment text, per Naoya Horiguchi]
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Hillf Danton <dhillf@gmail.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Tested-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index acd2010328f3..85e0c58bdfdf 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -69,7 +69,6 @@ int dequeue_hwpoisoned_huge_page(struct page *page);
 bool isolate_huge_page(struct page *page, struct list_head *list);
 void putback_active_hugepage(struct page *page);
 bool is_hugepage_active(struct page *page);
-void copy_huge_page(struct page *dst, struct page *src);
 
 #ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE
 pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud);
@@ -140,9 +139,6 @@ static inline int dequeue_hwpoisoned_huge_page(struct page *page)
 #define isolate_huge_page(p, l) false
 #define putback_active_hugepage(p)	do {} while (0)
 #define is_hugepage_active(x)	false
-static inline void copy_huge_page(struct page *dst, struct page *src)
-{
-}
 
 static inline unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
 		unsigned long address, unsigned long end, pgprot_t newprot)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 7d57af21f49e..2130365d387d 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -476,40 +476,6 @@ static int vma_has_reserves(struct vm_area_struct *vma, long chg)
 	return 0;
 }
 
-static void copy_gigantic_page(struct page *dst, struct page *src)
-{
-	int i;
-	struct hstate *h = page_hstate(src);
-	struct page *dst_base = dst;
-	struct page *src_base = src;
-
-	for (i = 0; i < pages_per_huge_page(h); ) {
-		cond_resched();
-		copy_highpage(dst, src);
-
-		i++;
-		dst = mem_map_next(dst, dst_base, i);
-		src = mem_map_next(src, src_base, i);
-	}
-}
-
-void copy_huge_page(struct page *dst, struct page *src)
-{
-	int i;
-	struct hstate *h = page_hstate(src);
-
-	if (unlikely(pages_per_huge_page(h) > MAX_ORDER_NR_PAGES)) {
-		copy_gigantic_page(dst, src);
-		return;
-	}
-
-	might_sleep();
-	for (i = 0; i < pages_per_huge_page(h); i++) {
-		cond_resched();
-		copy_highpage(dst + i, src + i);
-	}
-}
-
 static void enqueue_huge_page(struct hstate *h, struct page *page)
 {
 	int nid = page_to_nid(page);
diff --git a/mm/migrate.c b/mm/migrate.c
index 316e720a2023..bb940045fe85 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -442,6 +442,54 @@ int migrate_huge_page_move_mapping(struct address_space *mapping,
 }
 
 /*
+ * Gigantic pages are so large that we do not guarantee that page++ pointer
+ * arithmetic will work across the entire page.  We need something more
+ * specialized.
+ */
+static void __copy_gigantic_page(struct page *dst, struct page *src,
+				int nr_pages)
+{
+	int i;
+	struct page *dst_base = dst;
+	struct page *src_base = src;
+
+	for (i = 0; i < nr_pages; ) {
+		cond_resched();
+		copy_highpage(dst, src);
+
+		i++;
+		dst = mem_map_next(dst, dst_base, i);
+		src = mem_map_next(src, src_base, i);
+	}
+}
+
+static void copy_huge_page(struct page *dst, struct page *src)
+{
+	int i;
+	int nr_pages;
+
+	if (PageHuge(src)) {
+		/* hugetlbfs page */
+		struct hstate *h = page_hstate(src);
+		nr_pages = pages_per_huge_page(h);
+
+		if (unlikely(nr_pages > MAX_ORDER_NR_PAGES)) {
+			__copy_gigantic_page(dst, src, nr_pages);
+			return;
+		}
+	} else {
+		/* thp page */
+		BUG_ON(!PageTransHuge(src));
+		nr_pages = hpage_nr_pages(src);
+	}
+
+	for (i = 0; i < nr_pages; i++) {
+		cond_resched();
+		copy_highpage(dst + i, src + i);
+	}
+}
+
+/*
  * Copy the page to its new location
  */
 void migrate_page_copy(struct page *newpage, struct page *page)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008

[Jiri Slaby]

On 03/29/2015, 01:25 AM, Hugh Dickins wrote:
> But you are very appositely mistaken: copy_huge_page() used to make
> the same mistake, and Dave Hansen fixed it back in v3.13, but the fix
> never went to the stable trees.
> 
> Your report was on an Ubuntu "3.11.0-15" kernel: I think Ubuntu have
> discontinued their 3.11-stable kernel series, but 3.10-longterm and
> 3.12-longterm would benefit from including this fix.  I haven't tried
> patching and  building and testing it there, but it looks reasonable.
> 
> Hugh
> 
> commit 30b0a105d9f7141e4cbf72ae5511832457d89788
> Author: Dave Hansen <dave.hansen@linux.intel.com>
> Date:   Thu Nov 21 14:31:58 2013 -0800
> 
>     mm: thp: give transparent hugepage code a separate copy_page

Applied to 3.12. Thanks.

-- 
js
suse labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008

[Andrey Korolyov]

On Sun, Mar 29, 2015 at 3:25 AM, Hugh Dickins <hughd@google.com> wrote:
> On Sat, 28 Mar 2015, Andrey Korolyov wrote:
>> On Tue, Feb 24, 2015 at 3:12 AM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
>> > On Wed, Feb 04, 2015 at 08:34:04PM +0400, Andrey Korolyov wrote:
>> >> >Hi,
>> >> >
>> >> >I've seen the problem quite a few times.  Before spending more time on
>> >> >it, I'd like to have a quick check here to see if anyone ever saw the
>> >> >same problem?  Hope it is a relevant question with this mail list.
>> >> >
>> >> >
>> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.078623] BUG: unable to handle
>> >> >kernel NULL pointer dereference at 0000000000000008
>> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.078916] IP: [<ffffffff8118d0fa>]
>> >> >copy_huge_page+0x8a/0x2a0
>> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079128] PGD 0
>> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079198] Oops: 0000 [#1] SMP
>> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.079319] Modules linked in:
>> >> >ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE
>> >> >iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
>> >> >xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
>> >> >iptable_filter ip_tables x_tables kvm_intel kvm bridge stp llc ast ttm
>> >> >drm_kms_helper drm sysimgblt sysfillrect syscopyarea lp mei_me ioatdma
>> >> >ext2 parport mei shpchp dcdbas joydev mac_hid lpc_ich acpi_pad wmi
>> >> >hid_generic usbhid hid ixgbe igb dca i2c_algo_bit ahci ptp libahci
>> >> >mdio pps_core
>> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081090] CPU: 19 PID: 3494 Comm:
>> >> >qemu-system-x86 Not tainted 3.11.0-15-generic #25~precise1-Ubuntu
>> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081424] Hardware name: Dell Inc.
>> >> >PowerEdge C6220 II/09N44V, BIOS 2.0.3 07/03/2013
>> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081705] task: ffff881026750000
>> >> >ti: ffff881026056000 task.ti: ffff881026056000
>> >> >Jul  2 11:08:21 arno-3 kernel: [ 2165.081973] RIP:
>> >> >0010:[<ffffffff8118d0fa>]  [<ffffffff8118d0fa>]
>> >> >copy_huge_page+0x8a/0x2a0
>> >>
>> >>
>> >> Hello,
>> >>
>> >> sorry for possible top-posting, the same issue appears on at least
>> >> 3.10 LTS series. The original thread is at
>> >> http://marc.info/?l=kvm&m=14043742300901.
>> >
>> > Andrey,
>> >
>> > I am unable to access the URL above?
>> >
>> >> The necessary components for failure to reappear are a single running
>> >> kvm guest and mounted large thp: hugepagesz=1G (seemingly the same as
>> >> in initial report). With default 2M pages everything is working well,
>> >> the same for 3.18 with 1G THP. Are there any obvious clues for the
>> >> issue?
>> >>
>> >> Thanks!
>> >
>> >
>>
>> Hello,
>>
>> Marcelo, sorry, I`ve missed your reply in time. The working link, for
>> example is http://www.spinics.net/lists/linux-mm/msg75658.html. The
>> reproducer is a very simple, you need 1G THP and mounted hugetlbfs.
>> What is interesting, if guest is backed by THP like '-object
>> memory-backend-file,id=mem,size=1G,mem-path=/hugepages,share=on' the
>> failure is less likely to occur.
>
> I think you're mistaken when you write of "1G THP": although hugetlbfs
> can support 1G hugepages, we don't support that size with Transparent
> Huge Pages.
>
> But you are very appositely mistaken: copy_huge_page() used to make
> the same mistake, and Dave Hansen fixed it back in v3.13, but the fix
> never went to the stable trees.
>
> Your report was on an Ubuntu "3.11.0-15" kernel: I think Ubuntu have
> discontinued their 3.11-stable kernel series, but 3.10-longterm and
> 3.12-longterm would benefit from including this fix.  I haven't tried
> patching and  building and testing it there, but it looks reasonable.
>
> Hugh
>
> commit 30b0a105d9f7141e4cbf72ae5511832457d89788
> Author: Dave Hansen <dave.hansen@linux.intel.com>
> Date:   Thu Nov 21 14:31:58 2013 -0800
>
>     mm: thp: give transparent hugepage code a separate copy_page
>
>     Right now, the migration code in migrate_page_copy() uses copy_huge_page()
>     for hugetlbfs and thp pages:
>
>            if (PageHuge(page) || PageTransHuge(page))
>                     copy_huge_page(newpage, page);
>
>     So, yay for code reuse.  But:
>
>       void copy_huge_page(struct page *dst, struct page *src)
>       {
>             struct hstate *h = page_hstate(src);
>
>     and a non-hugetlbfs page has no page_hstate().  This works 99% of the
>     time because page_hstate() determines the hstate from the page order
>     alone.  Since the page order of a THP page matches the default hugetlbfs
>     page order, it works.
>
>     But, if you change the default huge page size on the boot command-line
>     (say default_hugepagesz=1G), then we might not even *have* a 2MB hstate
>     so page_hstate() returns null and copy_huge_page() oopses pretty fast
>     since copy_huge_page() dereferences the hstate:
>
>       void copy_huge_page(struct page *dst, struct page *src)
>       {
>             struct hstate *h = page_hstate(src);
>             if (unlikely(pages_per_huge_page(h) > MAX_ORDER_NR_PAGES)) {
>       ...
>
>     Mel noticed that the migration code is really the only user of these
>     functions.  This moves all the copy code over to migrate.c and makes
>     copy_huge_page() work for THP by checking for it explicitly.
>
>     I believe the bug was introduced in commit b32967ff101a ("mm: numa: Add
>     THP migration for the NUMA working set scanning fault case")
>
>     [akpm@linux-foundation.org: fix coding-style and comment text, per Naoya Horiguchi]
>     Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
>     Acked-by: Mel Gorman <mgorman@suse.de>
>     Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>     Cc: Hillf Danton <dhillf@gmail.com>
>     Cc: Andrea Arcangeli <aarcange@redhat.com>
>     Tested-by: Dave Jiang <dave.jiang@intel.com>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index acd2010328f3..85e0c58bdfdf 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -69,7 +69,6 @@ int dequeue_hwpoisoned_huge_page(struct page *page);
>  bool isolate_huge_page(struct page *page, struct list_head *list);
>  void putback_active_hugepage(struct page *page);
>  bool is_hugepage_active(struct page *page);
> -void copy_huge_page(struct page *dst, struct page *src);
>
>  #ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE
>  pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud);
> @@ -140,9 +139,6 @@ static inline int dequeue_hwpoisoned_huge_page(struct page *page)
>  #define isolate_huge_page(p, l) false
>  #define putback_active_hugepage(p)     do {} while (0)
>  #define is_hugepage_active(x)  false
> -static inline void copy_huge_page(struct page *dst, struct page *src)
> -{
> -}
>
>  static inline unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
>                 unsigned long address, unsigned long end, pgprot_t newprot)
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 7d57af21f49e..2130365d387d 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -476,40 +476,6 @@ static int vma_has_reserves(struct vm_area_struct *vma, long chg)
>         return 0;
>  }
>
> -static void copy_gigantic_page(struct page *dst, struct page *src)
> -{
> -       int i;
> -       struct hstate *h = page_hstate(src);
> -       struct page *dst_base = dst;
> -       struct page *src_base = src;
> -
> -       for (i = 0; i < pages_per_huge_page(h); ) {
> -               cond_resched();
> -               copy_highpage(dst, src);
> -
> -               i++;
> -               dst = mem_map_next(dst, dst_base, i);
> -               src = mem_map_next(src, src_base, i);
> -       }
> -}
> -
> -void copy_huge_page(struct page *dst, struct page *src)
> -{
> -       int i;
> -       struct hstate *h = page_hstate(src);
> -
> -       if (unlikely(pages_per_huge_page(h) > MAX_ORDER_NR_PAGES)) {
> -               copy_gigantic_page(dst, src);
> -               return;
> -       }
> -
> -       might_sleep();
> -       for (i = 0; i < pages_per_huge_page(h); i++) {
> -               cond_resched();
> -               copy_highpage(dst + i, src + i);
> -       }
> -}
> -
>  static void enqueue_huge_page(struct hstate *h, struct page *page)
>  {
>         int nid = page_to_nid(page);
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 316e720a2023..bb940045fe85 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -442,6 +442,54 @@ int migrate_huge_page_move_mapping(struct address_space *mapping,
>  }
>
>  /*
> + * Gigantic pages are so large that we do not guarantee that page++ pointer
> + * arithmetic will work across the entire page.  We need something more
> + * specialized.
> + */
> +static void __copy_gigantic_page(struct page *dst, struct page *src,
> +                               int nr_pages)
> +{
> +       int i;
> +       struct page *dst_base = dst;
> +       struct page *src_base = src;
> +
> +       for (i = 0; i < nr_pages; ) {
> +               cond_resched();
> +               copy_highpage(dst, src);
> +
> +               i++;
> +               dst = mem_map_next(dst, dst_base, i);
> +               src = mem_map_next(src, src_base, i);
> +       }
> +}
> +
> +static void copy_huge_page(struct page *dst, struct page *src)
> +{
> +       int i;
> +       int nr_pages;
> +
> +       if (PageHuge(src)) {
> +               /* hugetlbfs page */
> +               struct hstate *h = page_hstate(src);
> +               nr_pages = pages_per_huge_page(h);
> +
> +               if (unlikely(nr_pages > MAX_ORDER_NR_PAGES)) {
> +                       __copy_gigantic_page(dst, src, nr_pages);
> +                       return;
> +               }
> +       } else {
> +               /* thp page */
> +               BUG_ON(!PageTransHuge(src));
> +               nr_pages = hpage_nr_pages(src);
> +       }
> +
> +       for (i = 0; i < nr_pages; i++) {
> +               cond_resched();
> +               copy_highpage(dst + i, src + i);
> +       }
> +}
> +
> +/*
>   * Copy the page to its new location
>   */
>  void migrate_page_copy(struct page *newpage, struct page *page)

Thanks, the issue is fixed on 3.10 with trivial patch modification.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008

[Andrey Korolyov]

>> But you are very appositely mistaken: copy_huge_page() used to make
>> the same mistake, and Dave Hansen fixed it back in v3.13, but the fix
>> never went to the stable trees.
>>
>> commit 30b0a105d9f7141e4cbf72ae5511832457d89788
>> Author: Dave Hansen <dave.hansen@linux.intel.com>
>> Date:   Thu Nov 21 14:31:58 2013 -0800
>>
>>     mm: thp: give transparent hugepage code a separate copy_page
>>
>>     Right now, the migration code in migrate_page_copy() uses copy_huge_page()
>>     for hugetlbfs and thp pages:
>>
>>            if (PageHuge(page) || PageTransHuge(page))
>>                     copy_huge_page(newpage, page);
>>
>>     So, yay for code reuse.  But:
>>
>>       void copy_huge_page(struct page *dst, struct page *src)
>>       {
>>             struct hstate *h = page_hstate(src);
>>
>>     and a non-hugetlbfs page has no page_hstate().  This works 99% of the
>>     time because page_hstate() determines the hstate from the page order
>>     alone.  Since the page order of a THP page matches the default hugetlbfs
>>     page order, it works.
>>
>>     But, if you change the default huge page size on the boot command-line
>>     (say default_hugepagesz=1G), then we might not even *have* a 2MB hstate
>>     so page_hstate() returns null and copy_huge_page() oopses pretty fast
>>     since copy_huge_page() dereferences the hstate:
>>
>>       void copy_huge_page(struct page *dst, struct page *src)
>>       {
>>             struct hstate *h = page_hstate(src);
>>             if (unlikely(pages_per_huge_page(h) > MAX_ORDER_NR_PAGES)) {
>>       ...
>>
>>     Mel noticed that the migration code is really the only user of these
>>     functions.  This moves all the copy code over to migrate.c and makes
>>     copy_huge_page() work for THP by checking for it explicitly.
>>
>>     I believe the bug was introduced in commit b32967ff101a ("mm: numa: Add
>>     THP migration for the NUMA working set scanning fault case")
>>
>>     [akpm@linux-foundation.org: fix coding-style and comment text, per Naoya Horiguchi]
>>     Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
>>     Acked-by: Mel Gorman <mgorman@suse.de>
>>     Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>>     Cc: Hillf Danton <dhillf@gmail.com>
>>     Cc: Andrea Arcangeli <aarcange@redhat.com>
>>     Tested-by: Dave Jiang <dave.jiang@intel.com>
>>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>
>
> Thanks, the issue is fixed on 3.10 with trivial patch modification.

Ping? 3.10 still misses that..

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008

[jipan yang]

cc linux-mm as suggested by Wanpeng.

[ 2423.567961] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000008
[ 2423.568252] IP: [<ffffffff8118d0fa>] copy_huge_page+0x8a/0x2a0
[ 2423.568465] PGD 0
[ 2423.568535] Oops: 0000 [#1] SMP
[ 2423.568658] Modules linked in: ip6table_filter ip6_tables
ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT
xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables
kvm_intel kvm bridge stp ast ttm drm_kms_helper drm llc sysimgblt
sysfillrect syscopyarea ioatdma shpchp joydev dcdbas mei_me mei
mac_hid lpc_ich acpi_pad wmi lp ext2 parport hid_generic usbhid hid
ixgbe igb ahci dca i2c_algo_bit libahci ptp pps_core mdio
[ 2423.570426] CPU: 16 PID: 2869 Comm: qemu-system-x86 Not tainted
3.11.0-15-generic #25~precise1-Ubuntu
[ 2423.570763] Hardware name: Dell Inc. PowerEdge C6220 II/09N44V,
BIOS 2.0.3 07/03/2013
[ 2423.571046] task: ffff88101de89770 ti: ffff88101df22000 task.ti:
ffff88101df22000
[ 2423.571314] RIP: 0010:[<ffffffff8118d0fa>]  [<ffffffff8118d0fa>]
copy_huge_page+0x8a/0x2a0
[ 2423.571609] RSP: 0018:ffff88101df23768  EFLAGS: 00010246
[ 2423.571797] RAX: 0000000000200000 RBX: ffffffff81f9aa20 RCX: 0000000000000012
[ 2423.572052] RDX: ffffffff81f9aa20 RSI: 0000000000001000 RDI: ffffea007bf20000
[ 2423.572307] RBP: ffff88101df237b8 R08: 0000000000000000 R09: 0000000000000200
[ 2423.572562] R10: 0000000000000000 R11: 0000000000017960 R12: ffffea007bf20000
[ 2423.572816] R13: 0000000000000001 R14: 020400000008407d R15: ffffea0040438000
[ 2423.573074] FS:  00007f40cffff700(0000) GS:ffff88203eec0000(0000)
knlGS:0000000000000000
[ 2423.573366] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2423.573570] CR2: 0000000000000008 CR3: 0000002024247000 CR4: 00000000001427e0
[ 2423.573825] Stack:
[ 2423.573889]  ffff88101df23788 ffffffff81156460 ffff88207fff8000
ffffea007bf20000
[ 2423.574151]  ffff88101df23798 ffffea0040438000 ffffea007bf20000
0000000000000001
[ 2423.574414]  020400000008407d ffff88101b341250 ffff88101df237e8
ffffffff8119fee9
[ 2423.574675] Call Trace:
[ 2423.574765]  [<ffffffff81156460>] ? put_compound_page+0x40/0x70
[ 2423.574980]  [<ffffffff8119fee9>] migrate_page_copy+0x39/0x250
[ 2423.575190]  [<ffffffff811a171c>]
migrate_misplaced_transhuge_page+0x16c/0x4d0
[ 2423.575454]  [<ffffffff811a4429>] do_huge_pmd_numa_page+0x169/0x2d0
[ 2423.575682]  [<ffffffff8115b92b>] ? putback_lru_page+0x5b/0xc0
[ 2423.575894]  [<ffffffff81174014>] handle_mm_fault+0x2c4/0x3e0
[ 2423.576103]  [<ffffffff8105a31a>] ? gup_pmd_range+0xaa/0xf0
[ 2423.576303]  [<ffffffff81174378>] __get_user_pages+0x178/0x5c0
[ 2423.576516]  [<ffffffff8105a340>] ? gup_pmd_range+0xd0/0xf0
[ 2423.576737]  [<ffffffffa0223bee>] hva_to_pfn_slow+0x9e/0x150 [kvm]
[ 2423.576971]  [<ffffffffa02258e5>] hva_to_pfn+0xd5/0x210 [kvm]
[ 2423.577188]  [<ffffffffa0225730>] ? kvm_release_pfn_clean+0x50/0x60 [kvm]
[ 2423.577452]  [<ffffffffa02463c8>] ? mmu_set_spte+0x138/0x270 [kvm]
[ 2423.577685]  [<ffffffffa0225acd>] __gfn_to_pfn_memslot+0xad/0xb0 [kvm]
[ 2423.577930]  [<ffffffffa0225b47>] __gfn_to_pfn+0x57/0x70 [kvm]
[ 2423.578149]  [<ffffffffa0225bba>] gfn_to_pfn_async+0x1a/0x20 [kvm]
[ 2423.578387]  [<ffffffffa024553a>] try_async_pf+0x4a/0x90 [kvm]
[ 2423.578607]  [<ffffffffa0227bbb>] ? kvm_host_page_size+0x9b/0xb0 [kvm]
[ 2423.587202]  [<ffffffffa0247c9b>] tdp_page_fault+0x10b/0x220 [kvm]
[ 2423.595850]  [<ffffffffa0244861>] kvm_mmu_page_fault+0x31/0x70 [kvm]
[ 2423.604557]  [<ffffffffa02b83de>] handle_ept_violation+0x7e/0x150 [kvm_intel]
[ 2423.613164]  [<ffffffffa02bc277>] vmx_handle_exit+0xa7/0x270 [kvm_intel]
[ 2423.621586]  [<ffffffffa023d1a7>] vcpu_enter_guest+0x447/0x770 [kvm]
[ 2423.629990]  [<ffffffffa02559c9>] ? kvm_apic_local_deliver+0x69/0x70 [kvm]
[ 2423.638546]  [<ffffffffa023d688>] __vcpu_run+0x1b8/0x2f0 [kvm]
[ 2423.646872]  [<ffffffffa023d85d>] kvm_arch_vcpu_ioctl_run+0x9d/0x170 [kvm]
[ 2423.654980]  [<ffffffffa022614b>] kvm_vcpu_ioctl+0x43b/0x600 [kvm]
[ 2423.662816]  [<ffffffff811c5f9c>] do_vfs_ioctl+0x7c/0x2f0
[ 2423.670388]  [<ffffffff811c62a1>] SyS_ioctl+0x91/0xb0
[ 2423.677695]  [<ffffffff8175099d>] system_call_fastpath+0x1a/0x1f
[ 2423.684854] Code: f9 81 48 d3 e6 48 39 c6 74 2a be 00 10 00 00 eb
0e 8b 4b 08 48 89 f7 48 d3 e7 48 39 c7 74 15 48 81 c3 60 0b 00 00 48
39 d3 72 e6 <8b> 0c 25 08 00 00 00 31 db 41 bc 01 00 00 00 44 89 e0 d3
e0 3d
[ 2423.699824] RIP  [<ffffffff8118d0fa>] copy_huge_page+0x8a/0x2a0
[ 2423.707111]  RSP <ffff88101df23768>
[ 2423.714230] CR2: 0000000000000008
[ 2423.784650] ---[ end trace f686f7a0c554a317 ]---
[ 2423.792015] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000008
[ 2423.799305] IP: [<ffffffff8118d0fa>] copy_huge_page+0x8a/0x2a0
[ 2423.806618] PGD 0
[ 2423.813866] Oops: 0000 [#2] SMP
[ 2423.821032] Modules linked in: ip6table_filter ip6_tables
ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT
xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables
kvm_intel kvm bridge stp ast ttm drm_kms_helper drm llc sysimgblt
sysfillrect syscopyarea ioatdma shpchp joydev dcdbas mei_me mei
mac_hid lpc_ich acpi_pad wmi lp ext2 parport hid_generic usbhid hid
ixgbe igb ahci dca i2c_algo_bit libahci ptp pps_core mdio
[ 2423.860767] CPU: 30 PID: 2868 Comm: qemu-system-x86 Tainted: G
D      3.11.0-15-generic #25~precise1-Ubuntu
[ 2423.869230] Hardware name: Dell Inc. PowerEdge C6220 II/09N44V,
BIOS 2.0.3 07/03/2013
[ 2423.877709] task: ffff88101de8c650 ti: ffff88101dcf6000 task.ti:
ffff88101dcf6000
[ 2423.886219] RIP: 0010:[<ffffffff8118d0fa>]  [<ffffffff8118d0fa>]
copy_huge_page+0x8a/0x2a0
[ 2423.894870] RSP: 0018:ffff88101dcf7768  EFLAGS: 00010246
[ 2423.903508] RAX: 0000000000200000 RBX: ffffffff81f9aa20 RCX: 0000000000000012
[ 2423.912224] RDX: ffffffff81f9aa20 RSI: 0000000000001000 RDI: ffffea007bf28000
[ 2423.920978] RBP: ffff88101dcf77b8 R08: 0000000000000000 R09: 0000000000000200
[ 2423.929723] R10: 0000000000000000 R11: 0000000000017960 R12: ffffea007bf28000
[ 2423.938533] R13: 0000000000000001 R14: 020400000008407d R15: ffffea0040430000
[ 2423.947276] FS:  00007f40d4a14700(0000) GS:ffff88203ef40000(0000)
knlGS:0000000000000000
[ 2423.956170] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2423.965049] CR2: 0000000000000008 CR3: 0000002024247000 CR4: 00000000001427e0
[ 2423.974071] Stack:
[ 2423.982952]  ffff88101dcf7788 ffffffff81156460 ffff88207fff8000
ffffea007bf28000
[ 2423.992109]  ffff88101dcf7798 ffffea0040430000 ffffea007bf28000
0000000000000001
[ 2424.001262]  020400000008407d ffff88101b341248 ffff88101dcf77e8
ffffffff8119fee9
[ 2424.010524] Call Trace:
[ 2424.019660]  [<ffffffff81156460>] ? put_compound_page+0x40/0x70
[ 2424.028987]  [<ffffffff8119fee9>] migrate_page_copy+0x39/0x250
[ 2424.038322]  [<ffffffff811a171c>]
migrate_misplaced_transhuge_page+0x16c/0x4d0
[ 2424.047705]  [<ffffffff811a4429>] do_huge_pmd_numa_page+0x169/0x2d0
[ 2424.057070]  [<ffffffff8116e441>] ? pte_offset_kernel+0x1/0x40
[ 2424.066392]  [<ffffffff81174014>] handle_mm_fault+0x2c4/0x3e0
[ 2424.075687]  [<ffffffff8105a31a>] ? gup_pmd_range+0xaa/0xf0
[ 2424.084969]  [<ffffffff81174378>] __get_user_pages+0x178/0x5c0
[ 2424.094200]  [<ffffffff8105a340>] ? gup_pmd_range+0xd0/0xf0
[ 2424.103406]  [<ffffffffa0223bee>] hva_to_pfn_slow+0x9e/0x150 [kvm]
[ 2424.112654]  [<ffffffffa02258e5>] hva_to_pfn+0xd5/0x210 [kvm]
[ 2424.121835]  [<ffffffffa0225730>] ? kvm_release_pfn_clean+0x50/0x60 [kvm]
[ 2424.131042]  [<ffffffffa02463c8>] ? mmu_set_spte+0x138/0x270 [kvm]
[ 2424.140272]  [<ffffffffa0225acd>] __gfn_to_pfn_memslot+0xad/0xb0 [kvm]
[ 2424.149499]  [<ffffffffa0225b47>] __gfn_to_pfn+0x57/0x70 [kvm]
[ 2424.158500]  [<ffffffffa0225bba>] gfn_to_pfn_async+0x1a/0x20 [kvm]
[ 2424.167356]  [<ffffffffa024553a>] try_async_pf+0x4a/0x90 [kvm]
[ 2424.176108]  [<ffffffffa0227bbb>] ? kvm_host_page_size+0x9b/0xb0 [kvm]
[ 2424.184821]  [<ffffffffa0247c9b>] tdp_page_fault+0x10b/0x220 [kvm]
[ 2424.193567]  [<ffffffffa0244861>] kvm_mmu_page_fault+0x31/0x70 [kvm]
[ 2424.202318]  [<ffffffffa02b83de>] handle_ept_violation+0x7e/0x150 [kvm_intel]
[ 2424.211047]  [<ffffffffa02bc277>] vmx_handle_exit+0xa7/0x270 [kvm_intel]
[ 2424.219700]  [<ffffffffa023d1a7>] vcpu_enter_guest+0x447/0x770 [kvm]
[ 2424.228314]  [<ffffffffa023d688>] __vcpu_run+0x1b8/0x2f0 [kvm]
[ 2424.237033]  [<ffffffffa023d85d>] kvm_arch_vcpu_ioctl_run+0x9d/0x170 [kvm]
[ 2424.245528]  [<ffffffffa022614b>] kvm_vcpu_ioctl+0x43b/0x600 [kvm]
[ 2424.253757]  [<ffffffff811c5f9c>] do_vfs_ioctl+0x7c/0x2f0
[ 2424.261712]  [<ffffffff811c62a1>] SyS_ioctl+0x91/0xb0
[ 2424.269378]  [<ffffffff81013dc5>] ? do_notify_resume+0x75/0xc0
[ 2424.276860]  [<ffffffff8175099d>] system_call_fastpath+0x1a/0x1f
[ 2424.284189] Code: f9 81 48 d3 e6 48 39 c6 74 2a be 00 10 00 00 eb
0e 8b 4b 08 48 89 f7 48 d3 e7 48 39 c7 74 15 48 81 c3 60 0b 00 00 48
39 d3 72 e6 <8b> 0c 25 08 00 00 00 31 db 41 bc 01 00 00 00 44 89 e0 d3
e0 3d
[ 2424.299626] RIP  [<ffffffff8118d0fa>] copy_huge_page+0x8a/0x2a0
[ 2424.306994]  RSP <ffff88101dcf7768>
[ 2424.314209] CR2: 0000000000000008
[ 2424.321342] ---[ end trace f686f7a0c554a318 ]---




root@arno-3:~# modinfo kvm
filename:       /lib/modules/3.11.0-15-generic/kernel/arch/x86/kvm/kvm.ko
license:        GPL
author:         Qumranet
srcversion:     9A23EA37F64E5A410C92557
depends:
intree:         Y
vermagic:       3.11.0-15-generic SMP mod_unload modversions
parm:           min_timer_period_us:uint
parm:           ignore_msrs:bool
parm:           tsc_tolerance_ppm:uint
parm:           allow_unsafe_assigned_interrupts:Enable device
assignment on platforms without interrupt remapping support. (bool)


root@arno-3:~# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.11.0-15-generic
root=/dev/mapper/arno--3--vg-root ro default_hugepagesz=1G
hugepagesz=1G hugepages=8 isolcpus=0-15


On Thu, Jul 3, 2014 at 1:08 AM, Wanpeng Li <wanpeng.li@linux.intel.com> wrote:
> You should also Cc mm ML
> On Thu, Jul 03, 2014 at 12:57:04AM -0700, jipan yang wrote:

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: copy_huge_page: unable to handle kernel NULL pointer dereference at 0000000000000008

[Wanpeng Li]

You should also Cc mm ML
On Thu, Jul 03, 2014 at 12:57:04AM -0700, jipan yang wrote:
>Hi,
>
>I've seen the problem quite a few times.  Before spending more time on
>it, I'd like to have a quick check here to see if anyone ever saw the
>same problem?  Hope it is a relevant question with this mail list.
>
>
>Jul  2 11:08:21 arno-3 kernel: [ 2165.078623] BUG: unable to handle
>kernel NULL pointer dereference at 0000000000000008
>Jul  2 11:08:21 arno-3 kernel: [ 2165.078916] IP: [<ffffffff8118d0fa>]
>copy_huge_page+0x8a/0x2a0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.079128] PGD 0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.079198] Oops: 0000 [#1] SMP
>Jul  2 11:08:21 arno-3 kernel: [ 2165.079319] Modules linked in:
>ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE
>iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
>xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
>iptable_filter ip_tables x_tables kvm_intel kvm bridge stp llc ast ttm
>drm_kms_helper drm sysimgblt sysfillrect syscopyarea lp mei_me ioatdma
>ext2 parport mei shpchp dcdbas joydev mac_hid lpc_ich acpi_pad wmi
>hid_generic usbhid hid ixgbe igb dca i2c_algo_bit ahci ptp libahci
>mdio pps_core
>Jul  2 11:08:21 arno-3 kernel: [ 2165.081090] CPU: 19 PID: 3494 Comm:
>qemu-system-x86 Not tainted 3.11.0-15-generic #25~precise1-Ubuntu
>Jul  2 11:08:21 arno-3 kernel: [ 2165.081424] Hardware name: Dell Inc.
>PowerEdge C6220 II/09N44V, BIOS 2.0.3 07/03/2013
>Jul  2 11:08:21 arno-3 kernel: [ 2165.081705] task: ffff881026750000
>ti: ffff881026056000 task.ti: ffff881026056000
>Jul  2 11:08:21 arno-3 kernel: [ 2165.081973] RIP:
>0010:[<ffffffff8118d0fa>]  [<ffffffff8118d0fa>]
>copy_huge_page+0x8a/0x2a0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.082267] RSP:
>0018:ffff881026057768  EFLAGS: 00010246
>Jul  2 11:08:21 arno-3 kernel: [ 2165.082455] RAX: 0000000000200000
>RBX: ffffffff81f9aa20 RCX: 0000000000000012
>Jul  2 11:08:21 arno-3 kernel: [ 2165.082710] RDX: ffffffff81f9aa20
>RSI: 0000000000001000 RDI: ffffea0077f28000
>Jul  2 11:08:21 arno-3 kernel: [ 2165.082963] RBP: ffff8810260577b8
>R08: 0000000000000000 R09: 00000000000001ff
>Jul  2 11:08:21 arno-3 kernel: [ 2165.083217] R10: ffffffffffffffff
>R11: 0000000000017960 R12: ffffea0077f28000
>Jul  2 11:08:21 arno-3 kernel: [ 2165.083471] R13: 0000000000000001
>R14: 020400000008407d R15: ffffea003a9b8000
>Jul  2 11:08:21 arno-3 kernel: [ 2165.083727] FS:
>00007f19d799a700(0000) GS:ffff88203ef20000(0000)
>knlGS:0000000000000000
>Jul  2 11:08:21 arno-3 kernel: [ 2165.084019] CS:  0010 DS: 0000 ES:
>0000 CR0: 0000000080050033
>Jul  2 11:08:21 arno-3 kernel: [ 2165.084222] CR2: 0000000000000008
>CR3: 0000002023b1c000 CR4: 00000000001427e0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.084477] Stack:
>Jul  2 11:08:21 arno-3 kernel: [ 2165.084540]  ffff881026057788
>ffffffff81156460 ffff88207fff8000 ffffea0077f28000
>Jul  2 11:08:21 arno-3 kernel: [ 2165.084802]  ffff881026057798
>ffffea003a9b8000 ffffea0077f28000 0000000000000001
>Jul  2 11:08:21 arno-3 kernel: [ 2165.085064]  020400000008407d
>ffff881026f11260 ffff8810260577e8 ffffffff8119fee9
>Jul  2 11:08:21 arno-3 kernel: [ 2165.085326] Call Trace:
>Jul  2 11:08:21 arno-3 kernel: [ 2165.085418]  [<ffffffff81156460>] ?
>put_compound_page+0x40/0x70
>Jul  2 11:08:21 arno-3 kernel: [ 2165.085633]  [<ffffffff8119fee9>]
>migrate_page_copy+0x39/0x250
>Jul  2 11:08:21 arno-3 kernel: [ 2165.085844]  [<ffffffff811a171c>]
>migrate_misplaced_transhuge_page+0x16c/0x4d0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.086106]  [<ffffffff811a4429>]
>do_huge_pmd_numa_page+0x169/0x2d0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.086332]  [<ffffffff81174014>]
>handle_mm_fault+0x2c4/0x3e0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.086539]  [<ffffffff81174378>]
>__get_user_pages+0x178/0x5c0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.086756]  [<ffffffff8105a340>] ?
>gup_pmd_range+0xd0/0xf0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.086972]  [<ffffffffa0228bee>]
>hva_to_pfn_slow+0x9e/0x150 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.087206]  [<ffffffffa022a8e5>]
>hva_to_pfn+0xd5/0x210 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.087423]  [<ffffffffa022a730>] ?
>kvm_release_pfn_clean+0x50/0x60 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.087686]  [<ffffffffa024b3c8>] ?
>mmu_set_spte+0x138/0x270 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.087920]  [<ffffffffa022aacd>]
>__gfn_to_pfn_memslot+0xad/0xb0 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.088166]  [<ffffffffa022ab47>]
>__gfn_to_pfn+0x57/0x70 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.088389]  [<ffffffffa022abba>]
>gfn_to_pfn_async+0x1a/0x20 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.088628]  [<ffffffffa024a53a>]
>try_async_pf+0x4a/0x90 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.088849]  [<ffffffffa022cbbb>] ?
>kvm_host_page_size+0x9b/0xb0 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.089098]  [<ffffffffa024cc9b>]
>tdp_page_fault+0x10b/0x220 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.089334]  [<ffffffffa0249861>]
>kvm_mmu_page_fault+0x31/0x70 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.098035]  [<ffffffffa02e03de>]
>handle_ept_violation+0x7e/0x150 [kvm_intel]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.106835]  [<ffffffffa02e4277>]
>vmx_handle_exit+0xa7/0x270 [kvm_intel]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.115677]  [<ffffffffa02421a7>]
>vcpu_enter_guest+0x447/0x770 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.124374]  [<ffffffff8107548f>] ?
>recalc_sigpending+0x1f/0x60
>Jul  2 11:08:21 arno-3 kernel: [ 2165.132901]  [<ffffffffa0242688>]
>__vcpu_run+0x1b8/0x2f0 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.141395]  [<ffffffffa024285d>]
>kvm_arch_vcpu_ioctl_run+0x9d/0x170 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.149999]  [<ffffffffa022b14b>]
>kvm_vcpu_ioctl+0x43b/0x600 [kvm]
>Jul  2 11:08:21 arno-3 kernel: [ 2165.158390]  [<ffffffff811c5f9c>]
>do_vfs_ioctl+0x7c/0x2f0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.166509]  [<ffffffff811c62a1>]
>SyS_ioctl+0x91/0xb0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.174332]  [<ffffffff81013dc5>] ?
>do_notify_resume+0x75/0xc0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.181934]  [<ffffffff8175099d>]
>system_call_fastpath+0x1a/0x1f
>Jul  2 11:08:21 arno-3 kernel: [ 2165.189323] Code: f9 81 48 d3 e6 48
>39 c6 74 2a be 00 10 00 00 eb 0e 8b 4b 08 48 89 f7 48 d3 e7 48 39 c7
>74 15 48 81 c3 60 0b 00 00 48 39 d3 72 e6 <8b> 0c 25 08 00 00 00 31 db
>41 bc 01 00 00 00 44 89 e0 d3 e0 3d
>Jul  2 11:08:21 arno-3 kernel: [ 2165.204645] RIP
>[<ffffffff8118d0fa>] copy_huge_page+0x8a/0x2a0
>Jul  2 11:08:21 arno-3 kernel: [ 2165.212110]  RSP <ffff881026057768>
>Jul  2 11:08:21 arno-3 kernel: [ 2165.219402] CR2: 0000000000000008
>Jul  2 11:08:21 arno-3 kernel: [ 2165.289865] ---[ end trace
>f74046a6ced0c2fb ]---
>
>
>
>root@arno-3:~# modinfo kvm
>filename:       /lib/modules/3.11.0-15-generic/kernel/arch/x86/kvm/kvm.ko
>license:        GPL
>author:         Qumranet
>srcversion:     9A23EA37F64E5A410C92557
>depends:
>intree:         Y
>vermagic:       3.11.0-15-generic SMP mod_unload modversions
>parm:           min_timer_period_us:uint
>parm:           ignore_msrs:bool
>parm:           tsc_tolerance_ppm:uint
>parm:           allow_unsafe_assigned_interrupts:Enable device
>assignment on platforms without interrupt remapping support. (bool)
>
>
>root@arno-3:~# cat /proc/cmdline
>BOOT_IMAGE=/vmlinuz-3.11.0-15-generic
>root=/dev/mapper/arno--3--vg-root ro default_hugepagesz=1G
>hugepagesz=1G hugepages=8 isolcpus=0-15
>
>
>root@arno-3:~# cat /proc/cpuinfo
>processor : 0
>vendor_id : GenuineIntel
>cpu family : 6
>model : 62
>model name : Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz
>stepping : 4
>microcode : 0x415
>cpu MHz : 1200.000
>cache size : 25600 KB
>physical id : 0
>siblings : 20
>core id : 0
>cpu cores : 10
>apicid : 0
>initial apicid : 0
>fpu : yes
>fpu_exception : yes
>cpuid level : 13
>wp : yes
>flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
>pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
>pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
>xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
>ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2
>x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida
>arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
>fsgsbase smep erms
>bogomips : 4399.71
>clflush size : 64
>cache_alignment : 64
>address sizes : 46 bits physical, 48 bits virtual
>power management:
>....................................................................
>processor : 39
>vendor_id : GenuineIntel
>cpu family : 6
>model : 62
>model name : Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz
>stepping : 4
>microcode : 0x415
>cpu MHz : 1200.000
>cache size : 25600 KB
>physical id : 1
>siblings : 20
>core id : 12
>cpu cores : 10
>apicid : 57
>initial apicid : 57
>fpu : yes
>fpu_exception : yes
>cpuid level : 13
>wp : yes
>flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
>pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
>pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
>xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
>ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2
>x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida
>arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
>fsgsbase smep erms
>bogomips : 4401.16
>clflush size : 64
>cache_alignment : 64
>address sizes : 46 bits physical, 48 bits virtual
>power management:
>
>root@arno-3:~#
>
>
> qemu-system-x86_64 -cpu host -boot c -drive
>file=./dev_stack_ubuntu_12_04.img  -m 4092 -cpu host  -smp 2 -device
>e1000,netdev=net0,mac=DE:AD:BE:EF:03:EF -netdev
>tap,id=net0,script=qemu-ifup  --enable-kvm  -monitor
>telnet:127.0.0.1:1234,server,nowait  -nographic -serial stdio -vnc :66
>
>Thanks,
>Jipan
>--
>To unsubscribe from this list: send the line "unsubscribe kvm" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>