From: Vasily Gorbik <gor@linux.ibm.com>
To: Daniel Axtens <dja@axtens.net>
Cc: kasan-dev@googlegroups.com, linux-mm@kvack.org, x86@kernel.org,
aryabinin@virtuozzo.com, glider@google.com, luto@kernel.org,
linux-kernel@vger.kernel.org, mark.rutland@arm.com,
dvyukov@google.com
Subject: Re: [PATCH v3 1/3] kasan: support backing vmalloc space with real shadow memory
Date: Fri, 9 Aug 2019 13:54:03 +0200 [thread overview]
Message-ID: <your-ad-here.call-01565351643-ext-1834@work.hours> (raw)
In-Reply-To: <20190731071550.31814-2-dja@axtens.net>
On Wed, Jul 31, 2019 at 05:15:48PM +1000, Daniel Axtens wrote:
> Hook into vmalloc and vmap, and dynamically allocate real shadow
> memory to back the mappings.
>
> Most mappings in vmalloc space are small, requiring less than a full
> page of shadow space. Allocating a full shadow page per mapping would
> therefore be wasteful. Furthermore, to ensure that different mappings
> use different shadow pages, mappings would have to be aligned to
> KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE.
>
> Instead, share backing space across multiple mappings. Allocate
> a backing page the first time a mapping in vmalloc space uses a
> particular page of the shadow region. Keep this page around
> regardless of whether the mapping is later freed - in the mean time
> the page could have become shared by another vmalloc mapping.
>
> This can in theory lead to unbounded memory growth, but the vmalloc
> allocator is pretty good at reusing addresses, so the practical memory
> usage grows at first but then stays fairly stable.
>
> This requires architecture support to actually use: arches must stop
> mapping the read-only zero page over portion of the shadow region that
> covers the vmalloc space and instead leave it unmapped.
>
> This allows KASAN with VMAP_STACK, and will be needed for architectures
> that do not have a separate module space (e.g. powerpc64, which I am
> currently working on). It also allows relaxing the module alignment
> back to PAGE_SIZE.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=202009
> Signed-off-by: Daniel Axtens <dja@axtens.net>
>
> ---
Acked-by: Vasily Gorbik <gor@linux.ibm.com>
I've added s390 specific kasan init part and the whole thing looks good!
Unfortunately I also had to make additional changes in s390 code, so
s390 part would go later through s390 tree. But looking forward seeing
your patch series upstream.
next prev parent reply other threads:[~2019-08-09 11:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-31 7:15 [PATCH v3 0/3] kasan: support backing vmalloc space with real shadow memory Daniel Axtens
2019-07-31 7:15 ` [PATCH v3 1/3] " Daniel Axtens
2019-08-08 13:50 ` Mark Rutland
2019-08-08 17:43 ` Mark Rutland
2019-08-09 9:54 ` Mark Rutland
2019-08-12 2:53 ` Daniel Axtens
2019-08-09 12:37 ` Mark Rutland
2019-08-09 11:54 ` Vasily Gorbik [this message]
2019-07-31 7:15 ` [PATCH v3 2/3] fork: support VMAP_STACK with KASAN_VMALLOC Daniel Axtens
2019-07-31 7:15 ` [PATCH v3 3/3] x86/kasan: support KASAN_VMALLOC Daniel Axtens
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=your-ad-here.call-01565351643-ext-1834@work.hours \
--to=gor@linux.ibm.com \
--cc=aryabinin@virtuozzo.com \
--cc=dja@axtens.net \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--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).