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 ECC87C433F5 for ; Wed, 24 Nov 2021 21:50:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 410186B0075; Wed, 24 Nov 2021 16:50:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 399156B0078; Wed, 24 Nov 2021 16:50:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2603F6B007B; Wed, 24 Nov 2021 16:50:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id 136556B0075 for ; Wed, 24 Nov 2021 16:50:28 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id CBB3C184FA09B for ; Wed, 24 Nov 2021 21:50:17 +0000 (UTC) X-FDA: 78845167674.16.56561FE Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf12.hostedemail.com (Postfix) with ESMTP id 5A3D410003D6 for ; Wed, 24 Nov 2021 21:50:17 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id D88DB61039; Wed, 24 Nov 2021 21:50:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1637790616; bh=sjkChDiLxaG1fCpG89gy7bcfc/T7jMB1IUewwOWd69o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Cm5wrgedyvLIRTjQ7KraWZ3OMr97ltyORBVps747E/UnLHJ470AEpQxKoEQe06P28 Wp/Zi2Y5PVjF6pTNJtWW+FoUlZMUhzCZaaSBDzdlg0AocxbvHjlbj6A/px2FBq3EK7 wAH7Ry0VJzAfA2TylGwac+4060fnhbNDAX3AqVeY= Date: Wed, 24 Nov 2021 13:50:14 -0800 From: Andrew Morton To: Kefeng Wang Cc: Andrey Ryabinin , Dmitry Vyukov , , , , , , Catalin Marinas , 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 v3] mm: Defer kmemleak object creation of module_alloc() Message-Id: <20211124135014.665649a0bcb872367b248cef@linux-foundation.org> In-Reply-To: <20211124142034.192078-1-wangkefeng.wang@huawei.com> References: <20211124142034.192078-1-wangkefeng.wang@huawei.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 5A3D410003D6 X-Stat-Signature: zyqeo386agqkaa4eju1xorfuihksxtfd Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=Cm5wrged; spf=pass (imf12.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1637790617-255633 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 Wed, 24 Nov 2021 22:20:34 +0800 Kefeng Wang wrote: > Yongqiang reports a kmemleak panic when module insmod/rmmod > with KASAN enabled(without KASAN_VMALLOC) on x86[1]. > > When the module area 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 check. > > module_alloc > __vmalloc_node_range > kmemleak_vmalloc > kmemleak_scan > update_checksum > kasan_module_alloc > kmemleak_ignore > > Note, there is no problem if KASAN_VMALLOC enabled, the modules > area entire shadow memory is preallocated. Thus, the bug only > exits on ARCH which supports dynamic allocation of module area > per module load, for now, only x86/arm64/s390 are involved. > > Add a VM_DEFER_KMEMLEAK flags, defer vmalloc'ed object register > of kmemleak in module_alloc() to fix this issue. > I guess this is worth backporting into -stable kernels? If so, what would be a suitable Fixes: target? I suspect it goes back to the initial KASAN merge date?