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 06603C433EF for ; Wed, 24 Nov 2021 05:13:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 73ED96B0075; Wed, 24 Nov 2021 00:13:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6ED566B0078; Wed, 24 Nov 2021 00:13:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DC506B007B; Wed, 24 Nov 2021 00:13:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id 4AC216B0075 for ; Wed, 24 Nov 2021 00:13:06 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0B14D8BEE3 for ; Wed, 24 Nov 2021 05:12:56 +0000 (UTC) X-FDA: 78842654394.10.751A7EE Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf07.hostedemail.com (Postfix) with ESMTP id E4F1B10002C2 for ; Wed, 24 Nov 2021 05:12:51 +0000 (UTC) Received: from dggpemm500022.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4HzTcN0v8kz8vYr; Wed, 24 Nov 2021 13:11:00 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 24 Nov 2021 13:12:50 +0800 Received: from [10.174.177.243] (10.174.177.243) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.20; Wed, 24 Nov 2021 13:12:50 +0800 Message-ID: <9f25b098-0253-4721-3b91-b7d3a79776c6@huawei.com> Date: Wed, 24 Nov 2021 13:12:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v2] mm: Delay kmemleak object creation of module_alloc() Content-Language: en-US To: Catalin Marinas CC: Andrey Ryabinin , Dmitry Vyukov , Andrew Morton , , , , , , Will Deacon , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Alexander Gordeev , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Alexander Potapenko , Yongqiang Liu References: <20211123143220.134361-1-wangkefeng.wang@huawei.com> From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggeme701-chm.china.huawei.com (10.1.199.97) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected X-Stat-Signature: ebnfm7gigb8objo31w7nw7aopcgmw4rh X-Rspamd-Queue-Id: E4F1B10002C2 X-Rspamd-Server: rspam07 Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-HE-Tag: 1637730771-22475 Content-Transfer-Encoding: quoted-printable 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 2021/11/24 3:44, Catalin Marinas wrote: > 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 succ= essfully, >> 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? My gcc could not support CC_HAS_KASAN_SW_TAGS, so no repoduced on ARM64 > > I have a suspicion there is no problem if KASAN_VMALLOC is enabled. Yes,=C2=A0 if KASAN_VMALLOC enabled, the memory of vmalloc shadow has bee= n=20 populated in arch's kasan_init(), there is no issue. but x86/arm64/s390 support dynamic allocation of=20 module area per module load by kasan_module_alloc(), and this leads the above concurrent issue. >> 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, un= signed long end, >> =20 >> #else /* CONFIG_KASAN_VMALLOC */ >> =20 >> -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)); >> =20 >> if (ret) { >> + struct vm_struct *vm =3D find_vm_area(addr); >> __memset(ret, KASAN_SHADOW_INIT, shadow_size); >> - find_vm_area(addr)->flags |=3D VM_KASAN; >> + vm->flags |=3D 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=3Dn. yes. > >> 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, u= nsigned long align, >> clear_vm_uninitialized_flag(area); >> =20 >> size =3D 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. See the definination, if KASAN_VMALLOC enabled, VM_DELAY_KMEMLEAK=C2=A0 i= s 0,=20 so kmemleak allocation still works. =20 +#if defined(CONFIG_KASAN) && (defined(CONFIG_KASAN_GENERIC) || \ + defined(CONFIG_KASAN_SW_TAGS)) && !defined(CONFIG_KASAN_VMALLOC) +#define VM_DELAY_KMEMLEAK 0x00000800 /* delay kmemleak object create */ +#else +#define VM_DELAY_KMEMLEAK 0 +#endif + > > 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). Will use DEFER instead. > > 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 coul= d > 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. Only the shadow of module area is dynamic allocation , this exists on=20 ARM64 too. if no KASAN_VMALLOC, no shadow area for vmalloc,=C2=A0 other vmalloc=20 allocation is no problem. Correct me if I'm wrong. Thanks. >