From: Dan Williams <dan.j.williams@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Nicolai Stange <nicstange@gmail.com>, Linux MM <linux-mm@kvack.org>
Subject: Re: [RFC 0/3] Regressions due to 7b79d10a2d64 ("mm: convert kmalloc_section_memmap() to populate_section_memmap()") and Kasan initialization on
Date: Wed, 15 Feb 2017 13:26:43 -0800 [thread overview]
Message-ID: <CAPcyv4gAUCsJ9HcSyAK6j4YDHPkJsb06ZX=uJsYBMDCNMFsNmQ@mail.gmail.com> (raw)
In-Reply-To: <20170215131023.02186e970498eca080c8d456@linux-foundation.org>
On Wed, Feb 15, 2017 at 1:10 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 15 Feb 2017 21:58:23 +0100 Nicolai Stange <nicstange@gmail.com> wrote:
>
>> Hi Dan,
>>
>> your recent commit 7b79d10a2d64 ("mm: convert kmalloc_section_memmap() to
>> populate_section_memmap()") seems to cause some issues with respect to
>> Kasan initialization on x86.
>>
>> This is because Kasan's initialization (ab)uses the arch provided
>> vmemmap_populate().
>>
>> The first one is a boot failure, see [1/3]. The commit before the
>> aforementioned one works fine.
>>
>> The second one, i.e. [2/3], is something that hit my eye while browsing
>> the source and I verified that this is indeed an issue by printk'ing and
>> dumping the page tables.
>>
>> The third one are excessive warnings from vmemmap_verify() due to Kasan's
>> NUMA_NO_NODE page populations.
>
> urggggh.
>
> That means these two series:
>
> mm-fix-type-width-of-section-to-from-pfn-conversion-macros.patch
> mm-devm_memremap_pages-use-multi-order-radix-for-zone_device-lookups.patch
> mm-introduce-struct-mem_section_usage-to-track-partial-population-of-a-section.patch
> mm-introduce-common-definitions-for-the-size-and-mask-of-a-section.patch
> mm-cleanup-sparse_init_one_section-return-value.patch
> mm-track-active-portions-of-a-section-at-boot.patch
> mm-track-active-portions-of-a-section-at-boot-fix.patch
> mm-track-active-portions-of-a-section-at-boot-fix-fix.patch
> mm-fix-register_new_memory-zone-type-detection.patch
> mm-convert-kmalloc_section_memmap-to-populate_section_memmap.patch
> mm-prepare-for-hot-add-remove-of-sub-section-ranges.patch
> mm-support-section-unaligned-zone_device-memory-ranges.patch
> mm-support-section-unaligned-zone_device-memory-ranges-fix.patch
> mm-support-section-unaligned-zone_device-memory-ranges-fix-2.patch
> mm-enable-section-unaligned-devm_memremap_pages.patch
> libnvdimm-pfn-dax-stop-padding-pmem-namespaces-to-section-alignment.patch
>
Yes, let's drop these and try again for 4.12. Thanks for the report
and the debug Nicolai!
> and
>
> mm-devm_memremap_pages-hold-device_hotplug-lock-over-mem_hotplug_begin-done.patch
> mm-validate-device_hotplug-is-held-for-memory-hotplug.patch
No, these are separate and are still valid for the merge window.
--
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>
next prev parent reply other threads:[~2017-02-15 21:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-15 20:58 Nicolai Stange
2017-02-15 20:58 ` [RFC 1/3] sparse-vmemmap: let vmemmap_populate_basepages() cover the whole range Nicolai Stange
2017-02-15 20:58 ` [RFC 2/3] sparse-vmemmap: make vmemmap_populate_basepages() skip HP mapped ranges Nicolai Stange
2017-02-15 20:58 ` [RFC 3/3] sparse-vmemmap: let vmemmap_verify() ignore NUMA_NO_NODE requests Nicolai Stange
2017-02-15 21:10 ` [RFC 0/3] Regressions due to 7b79d10a2d64 ("mm: convert kmalloc_section_memmap() to populate_section_memmap()") and Kasan initialization on Andrew Morton
2017-02-15 21:26 ` Dan Williams [this message]
2017-02-15 21:54 ` Andrew Morton
2017-02-25 19:03 ` Dan Williams
2017-02-27 9:34 ` Dmitry Vyukov
2017-03-03 16:08 ` Andrey Ryabinin
2017-03-10 0:58 ` Dan Williams
2017-03-10 8:46 ` Andrey Ryabinin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPcyv4gAUCsJ9HcSyAK6j4YDHPkJsb06ZX=uJsYBMDCNMFsNmQ@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=nicstange@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox