From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D58E7C433FE for ; Tue, 23 Nov 2021 19:45:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B0A46B006C; Tue, 23 Nov 2021 14:44:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 460D06B0071; Tue, 23 Nov 2021 14:44:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 328296B0072; Tue, 23 Nov 2021 14:44:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0045.hostedemail.com [216.40.44.45]) by kanga.kvack.org (Postfix) with ESMTP id 231E76B006C for ; Tue, 23 Nov 2021 14:44:57 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C0B7D183A39C3 for ; Tue, 23 Nov 2021 19:44:46 +0000 (UTC) X-FDA: 78841222278.19.A6F84D3 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf31.hostedemail.com (Postfix) with ESMTP id 460631046316 for ; Tue, 23 Nov 2021 19:44:40 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 0FE6160F26; Tue, 23 Nov 2021 19:44:39 +0000 (UTC) Date: Tue, 23 Nov 2021 19:44:35 +0000 From: Catalin Marinas To: Kefeng Wang Cc: Andrey Ryabinin , Dmitry Vyukov , Andrew Morton , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, Will Deacon , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Alexander Gordeev , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Alexander Potapenko , Yongqiang Liu Subject: Re: [PATCH v2] mm: Delay kmemleak object creation of module_alloc() Message-ID: References: <20211123143220.134361-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211123143220.134361-1-wangkefeng.wang@huawei.com> X-Stat-Signature: 55ft54mc6ijq36naorpt78fua3z86zmq X-Rspamd-Queue-Id: 460631046316 X-Rspamd-Server: rspam07 Authentication-Results: imf31.hostedemail.com; dkim=none; spf=pass (imf31.hostedemail.com: domain of cmarinas@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) X-HE-Tag: 1637696680-352354 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 23, 2021 at 10:32:20PM +0800, Kefeng Wang wrote: > Yongqiang reports a kmemleak panic when module insmod/rmmod with KASAN > enabled on x86[1]. > > When the module allocates memory, it's kmemleak_object is created successfully, > but the KASAN shadow memory of module allocation is not ready, so when kmemleak > scan the module's pointer, it will panic due to no shadow memory with KASAN. > > module_alloc > __vmalloc_node_range > kmemleak_vmalloc > kmemleak_scan > update_checksum > kasan_module_alloc > kmemleak_ignore Can you share the .config and the stack trace you get on arm64? I have a suspicion there is no problem if KASAN_VMALLOC is enabled. > diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c > index 4a4929b29a23..2ade2f484562 100644 > --- a/mm/kasan/shadow.c > +++ b/mm/kasan/shadow.c > @@ -498,7 +498,7 @@ void kasan_release_vmalloc(unsigned long start, unsigned long end, > > #else /* CONFIG_KASAN_VMALLOC */ > > -int kasan_module_alloc(void *addr, size_t size) > +int kasan_module_alloc(void *addr, size_t size, gfp_t gfp_mask) > { > void *ret; > size_t scaled_size; > @@ -520,9 +520,14 @@ int kasan_module_alloc(void *addr, size_t size) > __builtin_return_address(0)); > > if (ret) { > + struct vm_struct *vm = find_vm_area(addr); > __memset(ret, KASAN_SHADOW_INIT, shadow_size); > - find_vm_area(addr)->flags |= VM_KASAN; > + vm->flags |= VM_KASAN; > kmemleak_ignore(ret); > + > + if (vm->flags & VM_DELAY_KMEMLEAK) > + kmemleak_vmalloc(vm, size, gfp_mask); > + > return 0; > } This function only exists if CONFIG_KASAN_VMALLOC=n. > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index d2a00ad4e1dd..23c595b15839 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -3074,7 +3074,8 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align, > clear_vm_uninitialized_flag(area); > > size = PAGE_ALIGN(size); > - kmemleak_vmalloc(area, size, gfp_mask); > + if (!(vm_flags & VM_DELAY_KMEMLEAK)) > + kmemleak_vmalloc(area, size, gfp_mask); So with KASAN_VMALLOC enabled, we'll miss the kmemleak allocation. You could add an IS_ENABLED(CONFIG_KASAN_VMALLOC) check but I'm not particularly fond of the delay approach (also think DEFER is probably a better name). A quick fix would be to make KMEMLEAK depend on !KASAN || KASAN_VMALLOC. We'll miss KASAN_SW_TAGS with kmemleak but I think vmalloc support could be enabled for this as well. What does KASAN do with other vmalloc() allocations when !KASAN_VMALLOC? Can we not have a similar approach. I don't fully understand why the module vmalloc() is a special case. -- Catalin