| Message ID | 20190903145536.3390-1-dja@axtens.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | kasan: support backing vmalloc space with real shadow memory | expand |
Hi Daniel, Are any other patches required prior to this series ? I have tried to apply it on later powerpc/merge branch without success: [root@localhost linux-powerpc]# git am /root/Downloads/kasan-support-backing-vmalloc-space-with-real-shadow-memory\(1\).patch Applying: kasan: support backing vmalloc space with real shadow memory .git/rebase-apply/patch:389: trailing whitespace. * (1) (2) (3) error: patch failed: lib/Kconfig.kasan:142 error: lib/Kconfig.kasan: patch does not apply Patch failed at 0001 kasan: support backing vmalloc space with real shadow memory The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". [root@localhost linux-powerpc]# git am -3 /root/Downloads/kasan-support-backing-vmalloc-space-with-real-shadow-memory\(1\).patch Applying: kasan: support backing vmalloc space with real shadow memory error: sha1 information is lacking or useless (include/linux/vmalloc.h). error: could not build fake ancestor Patch failed at 0001 kasan: support backing vmalloc space with real shadow memory The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Christophe On 09/03/2019 02:55 PM, Daniel Axtens wrote: > 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. > > 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. > > > 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: Add a TLB flush on freeing, thanks Mark Rutland. > Explain more clearly how I think freeing is concurrency-safe. > > Daniel Axtens (5): > 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 > kasan debug: track pages allocated for vmalloc shadow > > Documentation/dev-tools/kasan.rst | 63 ++++++++ > arch/Kconfig | 9 +- > arch/x86/Kconfig | 1 + > arch/x86/mm/kasan_init_64.c | 60 ++++++++ > 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 | 230 ++++++++++++++++++++++++++++++ > mm/kasan/generic_report.c | 3 + > mm/kasan/kasan.h | 1 + > mm/vmalloc.c | 45 +++++- > 14 files changed, 497 insertions(+), 6 deletions(-) >
Hi Christophe, > Are any other patches required prior to this series ? I have tried to > apply it on later powerpc/merge branch without success: It applies on the latest linux-next. I didn't base it on powerpc/* because it's generic. Regards, Daniel
Le 11/09/2019 à 13:20, Daniel Axtens a écrit : > Hi Christophe, > >> Are any other patches required prior to this series ? I have tried to >> apply it on later powerpc/merge branch without success: > > It applies on the latest linux-next. I didn't base it on powerpc/* > because it's generic. > Ok, thanks. I backported it to powerpc/merge and I'm testing it on PPC32 with VMAP_STACK. Got a few challenges but it is working now. Christophe
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. 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. 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: Add a TLB flush on freeing, thanks Mark Rutland. Explain more clearly how I think freeing is concurrency-safe. Daniel Axtens (5): 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 kasan debug: track pages allocated for vmalloc shadow Documentation/dev-tools/kasan.rst | 63 ++++++++ arch/Kconfig | 9 +- arch/x86/Kconfig | 1 + arch/x86/mm/kasan_init_64.c | 60 ++++++++ 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 | 230 ++++++++++++++++++++++++++++++ mm/kasan/generic_report.c | 3 + mm/kasan/kasan.h | 1 + mm/vmalloc.c | 45 +++++- 14 files changed, 497 insertions(+), 6 deletions(-)