From: Andrey Ryabinin <aryabinin@virtuozzo.com>
To: Dan Williams <dan.j.williams@intel.com>,
Nicolai Stange <nicstange@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux MM <linux-mm@kvack.org>, Dmitry Vyukov <dvyukov@google.com>,
Alexander Potapenko <glider@google.com>
Subject: Re: [RFC 0/3] Regressions due to 7b79d10a2d64 ("mm: convert kmalloc_section_memmap() to populate_section_memmap()") and Kasan initialization on
Date: Fri, 3 Mar 2017 19:08:08 +0300 [thread overview]
Message-ID: <7ce861c2-0eff-9b60-e009-06b1fddf7b73@virtuozzo.com> (raw)
In-Reply-To: <CAPcyv4iwhkW+cLbsT1Ns4=DhnfvZvdhbEVmj0zZcS+PRP6GMpA@mail.gmail.com>
On 02/25/2017 10:03 PM, Dan Williams wrote:
> [ adding kasan folks ]
>
> On Wed, Feb 15, 2017 at 12:58 PM, 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.
>>
>>
>> I'll be travelling the next two days and certainly not be able to respond
>> or polish these patches any further. Furthermore, the next merge window is
>> close. So please, take these three patches as bug reports only, meant to
>> illustrate the issues. Feel free to use, change and adopt them however
>> you deemed best.
>>
>> That being said,
>> - [2/3] will break arm64 due to the current lack of a pmd_large().
>> - Maybe it's easier and better to restore former behaviour by letting
>> Kasan's shadow initialization on x86 use vmemmap_populate_hugepages()
>> directly rather than vmemmap_populate(). This would require x86_64
>> implying X86_FEATURE_PSE though. I'm not sure whether this holds,
>> in particular not since the vmemmap_populate() from
>> arch/x86/mm/init_64.c checks for it.
>
> I think your intuition is correct here, and yes, it is a safe
> assumption that x86_64 implies X86_FEATURE_PSE. The following patch
> works for me. If there's no objections I'll roll it into the series
> and resubmit the sub-section hotplug support after testing on top of
> 4.11-rc1.
>
Perhaps it would be better to get rid of vmemmap in kasan code at all
and have a separate function that populates kasan shadow.
kasan is abusing API designed for something else. We already had bugs on arm64 (see 2776e0e8ef683)
because of that and now this one on x86_64.
I can cook patches and send them on the next week.
--
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-03-03 16:07 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
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 [this message]
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=7ce861c2-0eff-9b60-e009-06b1fddf7b73@virtuozzo.com \
--to=aryabinin@virtuozzo.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--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