From: Daniel Axtens <dja@axtens.net> To: Marco Elver <elver@google.com>, Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Andrey Ryabinin <ryabinin.a.a@gmail.com>, Andrey Konovalov <andreyknvl@gmail.com>, Dmitry Vyukov <dvyukov@google.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org Subject: Re: [PATCH -next 3/3] kasan: arm64: Fix pcpu_page_first_chunk crash with KASAN_VMALLOC Date: Tue, 06 Jul 2021 10:05:41 +1000 [thread overview] Message-ID: <878s2kxq5m.fsf@dja-thinkpad.axtens.net> (raw) In-Reply-To: <87bl7gxq7k.fsf@dja-thinkpad.axtens.net> > If so, should we put the call inside of vm_area_register_early? Ah, we already do this. Sorry. My other questions remain. Kind regards, Daniel > > Kind regards, > Daniel > >> >>> void __init kasan_init(void) >>> { >>> kasan_init_shadow(); >>> diff --git a/include/linux/kasan.h b/include/linux/kasan.h >>> index 5310e217bd74..79d3895b0240 100644 >>> --- a/include/linux/kasan.h >>> +++ b/include/linux/kasan.h >>> @@ -49,6 +49,8 @@ extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D]; >>> int kasan_populate_early_shadow(const void *shadow_start, >>> const void *shadow_end); >>> >>> +void kasan_populate_early_vm_area_shadow(void *start, unsigned long size); >>> + >>> static inline void *kasan_mem_to_shadow(const void *addr) >>> { >>> return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT) >>> diff --git a/mm/kasan/init.c b/mm/kasan/init.c >>> index cc64ed6858c6..d39577d088a1 100644 >>> --- a/mm/kasan/init.c >>> +++ b/mm/kasan/init.c >>> @@ -279,6 +279,11 @@ int __ref kasan_populate_early_shadow(const void *shadow_start, >>> return 0; >>> } >>> >>> +void __init __weak kasan_populate_early_vm_area_shadow(void *start, >>> + unsigned long size) >>> +{ >>> +} >> >> I'm just wondering if this could be a generic function, perhaps with an >> appropriate IS_ENABLED() check of a generic Kconfig option >> (CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK ?) to short-circuit it, if it's >> not only an arm64 problem. >> >> But I haven't looked much further, so would appeal to you to either >> confirm or reject this idea. >> >> Thanks, >> -- Marco
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Axtens <dja@axtens.net> To: Marco Elver <elver@google.com>, Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Andrey Ryabinin <ryabinin.a.a@gmail.com>, Andrey Konovalov <andreyknvl@gmail.com>, Dmitry Vyukov <dvyukov@google.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org Subject: Re: [PATCH -next 3/3] kasan: arm64: Fix pcpu_page_first_chunk crash with KASAN_VMALLOC Date: Tue, 06 Jul 2021 10:05:41 +1000 [thread overview] Message-ID: <878s2kxq5m.fsf@dja-thinkpad.axtens.net> (raw) In-Reply-To: <87bl7gxq7k.fsf@dja-thinkpad.axtens.net> > If so, should we put the call inside of vm_area_register_early? Ah, we already do this. Sorry. My other questions remain. Kind regards, Daniel > > Kind regards, > Daniel > >> >>> void __init kasan_init(void) >>> { >>> kasan_init_shadow(); >>> diff --git a/include/linux/kasan.h b/include/linux/kasan.h >>> index 5310e217bd74..79d3895b0240 100644 >>> --- a/include/linux/kasan.h >>> +++ b/include/linux/kasan.h >>> @@ -49,6 +49,8 @@ extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D]; >>> int kasan_populate_early_shadow(const void *shadow_start, >>> const void *shadow_end); >>> >>> +void kasan_populate_early_vm_area_shadow(void *start, unsigned long size); >>> + >>> static inline void *kasan_mem_to_shadow(const void *addr) >>> { >>> return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT) >>> diff --git a/mm/kasan/init.c b/mm/kasan/init.c >>> index cc64ed6858c6..d39577d088a1 100644 >>> --- a/mm/kasan/init.c >>> +++ b/mm/kasan/init.c >>> @@ -279,6 +279,11 @@ int __ref kasan_populate_early_shadow(const void *shadow_start, >>> return 0; >>> } >>> >>> +void __init __weak kasan_populate_early_vm_area_shadow(void *start, >>> + unsigned long size) >>> +{ >>> +} >> >> I'm just wondering if this could be a generic function, perhaps with an >> appropriate IS_ENABLED() check of a generic Kconfig option >> (CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK ?) to short-circuit it, if it's >> not only an arm64 problem. >> >> But I haven't looked much further, so would appeal to you to either >> confirm or reject this idea. >> >> Thanks, >> -- Marco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-07-06 0:05 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-05 11:14 [PATCH -next 0/3] arm64: support page mapping percpu first chunk allocator Kefeng Wang 2021-07-05 11:14 ` Kefeng Wang 2021-07-05 11:14 ` [PATCH -next 1/3] vmalloc: Choose a better start address in vm_area_register_early() Kefeng Wang 2021-07-05 11:14 ` Kefeng Wang 2021-07-05 11:14 ` [PATCH -next 2/3] arm64: Support page mapping percpu first chunk allocator Kefeng Wang 2021-07-05 11:14 ` Kefeng Wang 2021-07-05 11:14 ` [PATCH -next 3/3] kasan: arm64: Fix pcpu_page_first_chunk crash with KASAN_VMALLOC Kefeng Wang 2021-07-05 11:14 ` Kefeng Wang 2021-07-05 14:10 ` kernel test robot 2021-07-05 14:10 ` kernel test robot 2021-07-05 14:10 ` kernel test robot 2021-07-06 4:12 ` Kefeng Wang 2021-07-06 4:12 ` Kefeng Wang 2021-07-06 4:12 ` Kefeng Wang 2021-07-05 15:04 ` Marco Elver 2021-07-05 15:04 ` Marco Elver 2021-07-06 0:04 ` Daniel Axtens 2021-07-06 0:04 ` Daniel Axtens 2021-07-06 0:05 ` Daniel Axtens [this message] 2021-07-06 0:05 ` Daniel Axtens 2021-07-06 4:07 ` Kefeng Wang 2021-07-16 5:06 ` Kefeng Wang 2021-07-16 7:41 ` Marco Elver 2021-07-16 7:41 ` Marco Elver 2021-07-16 7:41 ` Marco Elver 2021-07-17 2:40 ` Kefeng Wang 2021-07-17 2:40 ` Kefeng Wang 2021-07-05 17:15 ` kernel test robot 2021-07-05 17:15 ` kernel test robot 2021-07-05 17:15 ` kernel test robot
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=878s2kxq5m.fsf@dja-thinkpad.axtens.net \ --to=dja@axtens.net \ --cc=andreyknvl@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=dvyukov@google.com \ --cc=elver@google.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=ryabinin.a.a@gmail.com \ --cc=wangkefeng.wang@huawei.com \ --cc=will@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.