From: Pasha Tatashin <pasha.tatashin@oracle.com>
To: Mark Rutland <mark.rutland@arm.com>,
will.deacon@arm.com, catalin.marinas@arm.com
Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
x86@kernel.org, kasan-dev@googlegroups.com,
borntraeger@de.ibm.com, heiko.carstens@de.ibm.com,
davem@davemloft.net, willy@infradead.org, mhocko@kernel.org,
ard.biesheuvel@linaro.org, sam@ravnborg.org,
mgorman@techsingularity.net, steven.sistare@oracle.com,
daniel.m.jordan@oracle.com, bob.picco@oracle.com
Subject: Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function
Date: Tue, 3 Oct 2017 11:04:26 -0400 [thread overview]
Message-ID: <1e2dc0da-5eb8-3160-803a-262a3c506baf@oracle.com> (raw)
In-Reply-To: <20171003144845.GD4931@leverpostej>
Hi Mark,
I considered using a new *populate() function for shadow without using
vmemmap_populate(), but that makes things unnecessary complicated:
vmemmap_populate() has builtin:
1. large page support
2. device memory support
3. node locality support
4. several config based variants on different platforms
All of that will cause the code simply be duplicated on each platform
if we want to support that in kasan.
We could limit ourselves to only supporting base pages in memory by
using something like vmemmap_populate_basepages(), but that is a step
backward. Kasan benefits from using large pages now, why remove it?
So, the solution I provide is walking page table right after memory is
mapped. Since, we are using the actual page table, it is guaranteed that
we are not going to miss any mapped memory, and also it is in common
code, which makes things smaller and nicer.
Thank you,
Pasha
On 10/03/2017 10:48 AM, Mark Rutland wrote:
>
> I've given this a spin on arm64, and can confirm that it works.
>
> Given that this involes redundant walking of page tables, I still think
> it'd be preferable to have some common *_populate() helper that took a
> gfp argument, but I guess it's not the end of the world.
>
> I'll leave it to Will and Catalin to say whether they're happy with the
> page table walking and the new p{u,m}d_large() helpers added to arm64.
>
next prev parent reply other threads:[~2017-10-03 15:06 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 20:17 [PATCH v9 00/12] complete deferred page initialization Pavel Tatashin
2017-09-20 20:17 ` [PATCH v9 01/12] x86/mm: setting fields in deferred pages Pavel Tatashin
2017-10-03 12:26 ` Michal Hocko
2017-10-03 15:07 ` Pasha Tatashin
2017-09-20 20:17 ` [PATCH v9 02/12] sparc64/mm: " Pavel Tatashin
2017-10-03 12:28 ` Michal Hocko
2017-10-03 15:10 ` Pasha Tatashin
2017-09-20 20:17 ` [PATCH v9 03/12] mm: deferred_init_memmap improvements Pavel Tatashin
2017-10-03 12:57 ` Michal Hocko
2017-10-03 15:15 ` Pasha Tatashin
2017-10-03 16:01 ` Pasha Tatashin
2017-10-04 8:48 ` Michal Hocko
2017-09-20 20:17 ` [PATCH v9 04/12] sparc64: simplify vmemmap_populate Pavel Tatashin
2017-10-03 12:59 ` Michal Hocko
2017-10-03 15:20 ` Pasha Tatashin
2017-09-20 20:17 ` [PATCH v9 05/12] mm: defining memblock_virt_alloc_try_nid_raw Pavel Tatashin
2017-09-20 20:17 ` [PATCH v9 06/12] mm: zero struct pages during initialization Pavel Tatashin
2017-10-03 13:08 ` Michal Hocko
2017-10-03 15:22 ` Pasha Tatashin
2017-10-04 8:45 ` Michal Hocko
2017-10-04 12:26 ` Pasha Tatashin
2017-09-20 20:17 ` [PATCH v9 07/12] sparc64: optimized struct page zeroing Pavel Tatashin
2017-09-20 20:17 ` [PATCH v9 08/12] mm: zero reserved and unavailable struct pages Pavel Tatashin
2017-10-03 13:18 ` Michal Hocko
2017-10-03 15:29 ` Pasha Tatashin
2017-10-04 8:56 ` Michal Hocko
2017-10-04 12:40 ` Pasha Tatashin
2017-10-04 12:57 ` Michal Hocko
2017-10-04 13:28 ` Pasha Tatashin
2017-10-04 14:04 ` Michal Hocko
2017-10-04 15:08 ` Pasha Tatashin
2017-09-20 20:17 ` [PATCH v9 09/12] mm/kasan: kasan specific map populate function Pavel Tatashin
2017-10-03 14:48 ` Mark Rutland
2017-10-03 15:04 ` Pasha Tatashin [this message]
2017-10-09 17:13 ` Will Deacon
2017-10-09 17:51 ` Pavel Tatashin
2017-10-09 18:14 ` Michal Hocko
2017-10-09 18:48 ` Will Deacon
2017-10-09 18:22 ` Will Deacon
2017-10-09 18:42 ` Pavel Tatashin
2017-10-09 18:48 ` Will Deacon
2017-10-09 18:59 ` Pavel Tatashin
2017-10-09 19:02 ` Will Deacon
2017-10-09 19:07 ` Pavel Tatashin
2017-10-09 19:57 ` Pavel Tatashin
2017-09-20 20:17 ` [PATCH v9 10/12] x86/kasan: use kasan_map_populate() Pavel Tatashin
2017-09-20 20:17 ` [PATCH v9 11/12] arm64/kasan: " Pavel Tatashin
2017-09-20 20:17 ` [PATCH v9 12/12] mm: stop zeroing memory during allocation in vmemmap Pavel Tatashin
2017-10-03 13:19 ` Michal Hocko
2017-10-03 15:34 ` Pasha Tatashin
2017-10-03 20:26 ` Pasha Tatashin
2017-10-04 8:45 ` Michal Hocko
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=1e2dc0da-5eb8-3160-803a-262a3c506baf@oracle.com \
--to=pasha.tatashin@oracle.com \
--cc=ard.biesheuvel@linaro.org \
--cc=bob.picco@oracle.com \
--cc=borntraeger@de.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=daniel.m.jordan@oracle.com \
--cc=davem@davemloft.net \
--cc=heiko.carstens@de.ibm.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=sam@ravnborg.org \
--cc=sparclinux@vger.kernel.org \
--cc=steven.sistare@oracle.com \
--cc=will.deacon@arm.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/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
all inboxes | Powered by JetHome®