linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Daniel Axtens <dja@axtens.net>,
	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
Cc: linuxppc-dev@lists.ozlabs.org, gor@linux.ibm.com
Subject: Re: [PATCH v11 0/4] kasan: support backing vmalloc space with real shadow memory
Date: Mon, 2 Dec 2019 09:07:31 +0100	[thread overview]
Message-ID: <33b29093-5fbe-c648-a0b1-e3a8525c5631@c-s.fr> (raw)
In-Reply-To: <20191031093909.9228-1-dja@axtens.net>



Le 31/10/2019 à 10:39, Daniel Axtens a écrit :
> Currently, vmalloc space is backed by the early shadow page. This
> means that kasan is incompatible with VMAP_STACK.
> 
> This series provides a mechanism to back vmalloc space with real,
> dynamically allocated memory. I have only wired up x86, because that's
> the only currently supported arch I can work with easily, but it's
> very easy to wire up other architectures, and it appears that there is
> some work-in-progress code to do this on arm64 and s390.

There is also work for providing VMAP_STACK on powerpc32. There is a 
series waiting to be merged at 
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=145109

Christophe

> 
> This has been discussed before in the context of VMAP_STACK:
>   - https://bugzilla.kernel.org/show_bug.cgi?id=202009
>   - https://lkml.org/lkml/2018/7/22/198
>   - https://lkml.org/lkml/2019/7/19/822
> 
> In terms of implementation details:
> 
> 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 when a mapping in vmalloc space uses a particular page of
> the shadow region. This page can be shared by other vmalloc mappings
> later on.
> 
> We hook in to the vmap infrastructure to lazily clean up unused shadow
> memory.
> 
> Testing with test_vmalloc.sh on an x86 VM with 2 vCPUs shows that:
> 
>   - Turning on KASAN, inline instrumentation, without vmalloc, introuduces
>     a 4.1x-4.2x slowdown in vmalloc operations.
> 
>   - Turning this on introduces the following slowdowns over KASAN:
>       * ~1.76x slower single-threaded (test_vmalloc.sh performance)
>       * ~2.18x slower when both cpus are performing operations
>         simultaneously (test_vmalloc.sh sequential_test_order=1)
> 
> This is unfortunate but given that this is a debug feature only, not
> the end of the world. The benchmarks are also a stress-test for the
> vmalloc subsystem: they're not indicative of an overall 2x slowdown!
> 
> 
> v1: https://lore.kernel.org/linux-mm/20190725055503.19507-1-dja@axtens.net/
> v2: https://lore.kernel.org/linux-mm/20190729142108.23343-1-dja@axtens.net/
>   Address review comments:
>   - Patch 1: use kasan_unpoison_shadow's built-in handling of
>              ranges that do not align to a full shadow byte
>   - Patch 3: prepopulate pgds rather than faulting things in
> v3: https://lore.kernel.org/linux-mm/20190731071550.31814-1-dja@axtens.net/
>   Address comments from Mark Rutland:
>   - kasan_populate_vmalloc is a better name
>   - handle concurrency correctly
>   - various nits and cleanups
>   - relax module alignment in KASAN_VMALLOC case
> v4: https://lore.kernel.org/linux-mm/20190815001636.12235-1-dja@axtens.net/
>   Changes to patch 1 only:
>   - Integrate Mark's rework, thanks Mark!
>   - handle the case where kasan_populate_shadow might fail
>   - poision shadow on free, allowing the alloc path to just
>       unpoision memory that it uses
> v5: https://lore.kernel.org/linux-mm/20190830003821.10737-1-dja@axtens.net/
>   Address comments from Christophe Leroy:
>   - Fix some issues with my descriptions in commit messages and docs
>   - Dynamically free unused shadow pages by hooking into the vmap book-keeping
>   - Split out the test into a separate patch
>   - Optional patch to track the number of pages allocated
>   - minor checkpatch cleanups
> v6: https://lore.kernel.org/linux-mm/20190902112028.23773-1-dja@axtens.net/
>   Properly guard freeing pages in patch 1, drop debugging code.
> v7: https://lore.kernel.org/linux-mm/20190903145536.3390-1-dja@axtens.net/
>      Add a TLB flush on freeing, thanks Mark Rutland.
>      Explain more clearly how I think freeing is concurrency-safe.
> v8: https://lore.kernel.org/linux-mm/20191001065834.8880-1-dja@axtens.net/
>      rename kasan_vmalloc/shadow_pages to kasan/vmalloc_shadow_pages
> v9: https://lore.kernel.org/linux-mm/20191017012506.28503-1-dja@axtens.net/
>      (attempt to) address a number of review comments for patch 1.
> v10: https://lore.kernel.org/linux-mm/20191029042059.28541-1-dja@axtens.net/
>       - rebase on linux-next, pulling in Vlad's new work on splitting the
>         vmalloc locks.
>       - after much discussion of barriers, document where I think they
>         are needed and why. Thanks Mark and Andrey.
>       - clean up some TLB flushing and checkpatch bits
> v11: Address review comments from Andrey and Vlad, drop patch 5, add benchmarking
>       results.
> 
> Daniel Axtens (4):
>    kasan: support backing vmalloc space with real shadow memory
>    kasan: add test for vmalloc
>    fork: support VMAP_STACK with KASAN_VMALLOC
>    x86/kasan: support KASAN_VMALLOC
> 
>   Documentation/dev-tools/kasan.rst |  63 ++++++++
>   arch/Kconfig                      |   9 +-
>   arch/x86/Kconfig                  |   1 +
>   arch/x86/mm/kasan_init_64.c       |  61 ++++++++
>   include/linux/kasan.h             |  31 ++++
>   include/linux/moduleloader.h      |   2 +-
>   include/linux/vmalloc.h           |  12 ++
>   kernel/fork.c                     |   4 +
>   lib/Kconfig.kasan                 |  16 +++
>   lib/test_kasan.c                  |  26 ++++
>   mm/kasan/common.c                 | 231 ++++++++++++++++++++++++++++++
>   mm/kasan/generic_report.c         |   3 +
>   mm/kasan/kasan.h                  |   1 +
>   mm/vmalloc.c                      |  53 +++++--
>   14 files changed, 500 insertions(+), 13 deletions(-)
> 


      parent reply	other threads:[~2019-12-02  8:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31  9:39 [PATCH v11 0/4] kasan: support backing vmalloc space with real shadow memory Daniel Axtens
2019-10-31  9:39 ` [PATCH v11 1/4] " Daniel Axtens
2019-11-15 16:36   ` Qian Cai
2019-11-18  3:29     ` Daniel Axtens
2019-11-19  9:54       ` Andrey Ryabinin
2019-11-29 10:43         ` Dmitry Vyukov
2019-11-29 10:58           ` Dmitry Vyukov
2019-11-29 11:02             ` Dmitry Vyukov
2019-11-29 11:38               ` Andrey Ryabinin
2019-11-29 11:47                 ` Dmitry Vyukov
2019-11-29 11:53                   ` Andrey Ryabinin
2019-11-29 12:29                     ` Daniel Axtens
2019-11-29 12:45                       ` Dmitry Vyukov
2019-11-29 15:13                         ` Dmitry Vyukov
2019-11-29 15:15                       ` XFS check crash (WAS Re: [PATCH v11 1/4] kasan: support backing vmalloc space with real shadow memory) Qian Cai
2019-11-29 15:50                         ` Daniel Axtens
2019-11-29 12:09             ` [PATCH v11 1/4] kasan: support backing vmalloc space with real shadow memory Daniel Axtens
2019-11-29 12:15               ` Dmitry Vyukov
2019-11-20  5:27   ` [PATCH] update to "kasan: support backing vmalloc space with real shadow memory" Daniel Axtens
2019-10-31  9:39 ` [PATCH v11 2/4] kasan: add test for vmalloc Daniel Axtens
2019-10-31  9:39 ` [PATCH v11 3/4] fork: support VMAP_STACK with KASAN_VMALLOC Daniel Axtens
2019-10-31  9:39 ` [PATCH v11 4/4] x86/kasan: support KASAN_VMALLOC Daniel Axtens
2019-11-08 22:36 ` [PATCH v11 0/4] kasan: support backing vmalloc space with real shadow memory Andrey Ryabinin
2019-12-02  8:07 ` Christophe Leroy [this message]

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=33b29093-5fbe-c648-a0b1-e3a8525c5631@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=aryabinin@virtuozzo.com \
    --cc=dja@axtens.net \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=gor@linux.ibm.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.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).