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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> 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@xxxxxxxxxxxxxxx>
>> 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@xxxxxxxxxxxxxxxxxxxx: fix coding-style and comment text, per Naoya Horiguchi]
>>     Signed-off-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
>>     Acked-by: Mel Gorman <mgorman@xxxxxxx>
>>     Reviewed-by: Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx>
>>     Cc: Hillf Danton <dhillf@xxxxxxxxx>
>>     Cc: Andrea Arcangeli <aarcange@xxxxxxxxxx>
>>     Tested-by: Dave Jiang <dave.jiang@xxxxxxxxx>
>>     Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>>     Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
>>
>
> Thanks, the issue is fixed on 3.10 with trivial patch modification.

Ping? 3.10 still misses that..
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux