From: Will Deacon <will.deacon@arm.com>
To: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
catalin.marinas@arm.com, 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 <ard.biesheuvel@linaro.org>,
sam@ravnborg.org, mgorman@techsingularity.net,
Steve Sistare <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: Mon, 9 Oct 2017 20:02:13 +0100 [thread overview]
Message-ID: <20171009190213.GF30828@arm.com> (raw)
In-Reply-To: <CAOAebxs5s3DKV8f+Zw+LFVB98PE6cs=RwcOH8qEiU_MPLM9RvQ@mail.gmail.com>
Hi Pavel,
On Mon, Oct 09, 2017 at 02:59:09PM -0400, Pavel Tatashin wrote:
> > We have two table walks even with your patch series applied afaict: one in
> > our definition of vmemmap_populate (arch/arm64/mm/mmu.c) and this one
> > in the core code.
>
> I meant to say implementing two new page table walkers, not at runtime.
Ok, but I'm still missing why you think that is needed. What would be the
second page table walker that needs implementing?
> > My worry is that these are actually highly arch-specific, but will likely
> > grow more users in mm/ that assume things for all architectures that aren't
> > necessarily valid.
>
> I see, how about moving new kasan_map_populate() implementation into
> arch dependent code:
>
> arch/x86/mm/kasan_init_64.c
> arch/arm64/mm/kasan_init.c
>
> This way we won't need to add pmd_large()/pud_large() macros for arm64?
I guess we could implement that on arm64 using our current vmemmap_populate
logic and an explicit memset.
Will
next prev parent reply other threads:[~2017-10-09 19:02 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
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 [this message]
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=20171009190213.GF30828@arm.com \
--to=will.deacon@arm.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=pasha.tatashin@oracle.com \
--cc=sam@ravnborg.org \
--cc=sparclinux@vger.kernel.org \
--cc=steven.sistare@oracle.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;
as well as URLs for NNTP newsgroup(s).