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 ED74ED2E009 for ; Wed, 23 Oct 2024 01:48:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 54AF56B00B5; Tue, 22 Oct 2024 21:48:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FAEF6B00B7; Tue, 22 Oct 2024 21:48:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39B536B00B8; Tue, 22 Oct 2024 21:48:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 166316B00B5 for ; Tue, 22 Oct 2024 21:48:03 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 732061A064A for ; Wed, 23 Oct 2024 01:47:32 +0000 (UTC) X-FDA: 82703180616.25.29307DE Received: from out-176.mta0.migadu.com (out-176.mta0.migadu.com [91.218.175.176]) by imf05.hostedemail.com (Postfix) with ESMTP id 3B4A6100006 for ; Wed, 23 Oct 2024 01:47:29 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=TQAuaxtg; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf05.hostedemail.com: domain of hao.ge@linux.dev designates 91.218.175.176 as permitted sender) smtp.mailfrom=hao.ge@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729647969; a=rsa-sha256; cv=none; b=P1o7m/PLmJCbhQ3Y2lDKmXpb890iqEP3TgyhHRWNvrcQ3iRZPcNgcpiYJiuTsAhoaPcmsY Ckw4zhePwH7VMZYnT9kQVv46c4Fi+6K7gq6gF2NCtVAC3TcJTMPZtd0M4WsQSizYOXXKDi 4WjqeY+mnBOD91D17i3Js/PivFheeJs= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=TQAuaxtg; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf05.hostedemail.com: domain of hao.ge@linux.dev designates 91.218.175.176 as permitted sender) smtp.mailfrom=hao.ge@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729647969; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MDFJBdshtH3O5uElK6WI+zDS773xTGHMb24/nQ91nD8=; b=b5CNoVK6v0miUzdQXE5YD/3GZ68CacPQnX8tmUHnpBbI9gKFmcIeRJSWGfq6mlzUD5H6EV jIbH+KhRz5q31tKC5bG+jgDHqFJeyINdrnNeav4+Nkao+UV3ypG9WDfKfTZz+uXSeVF2EY Uv7Wth4I2Neu2aiuGjC4ZYhPAct9D+g= Message-ID: <32f70816-1678-d6ab-0db1-6412ff7a7333@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729648078; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MDFJBdshtH3O5uElK6WI+zDS773xTGHMb24/nQ91nD8=; b=TQAuaxtgN6g9r8X+gtHIzrwi15PdugMkQh6Knkh+dlDdcxpkMpQw+F6f8BJbAa3+gvCTFw b+zZ9ScruxvW9tB52aAWHhSGBgb8hNXOcTFig2B2s5Fljlp9Ipbd0OGqAchKi01/RSjbEG E04FzjxJHXahzDftsoyFUBzxL3AX0sQ= Date: Wed, 23 Oct 2024 09:47:25 +0800 MIME-Version: 1.0 Subject: Re: [PATCH] slub/slub_kunit:fix a panic due to __kmalloc_cache_noprof incorretly use To: Vlastimil Babka , Suren Baghdasaryan , xiaopeitux@foxmail.com Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, yuzhao@google.com, xiaopei01@kylinos.cn, gehao@kylinso.cn, xiongxin@kylinos.cn References: X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Hao Ge In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 3B4A6100006 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: oj6b5fmry49dkzxmgnbadie5obc9ifak X-HE-Tag: 1729648049-998337 X-HE-Meta: U2FsdGVkX19ENg3kFcHDrRpeAWP9DWhChaI8LquHF6CxNGwe8vOKx/xzuTSevL2Hf93e31bYWkdGqNwJwwWmceBYipG+9nDUXS0l06H4ohompaXmzc0209ueI1jyViPZ1T1NmVhJ0A2tvhWIrLktmUlWthcgWHnHUrrmLd79otnQn2cnP/WNKP0okMIkwz3JMlOzeAqKRN1XwhHdfwP8hI/DtUkfSdF6uKB2eZi65TC2qCMo9TAcZbrCb76GC0ebAsReNE4ToPACAx1N4yyXntoR4HeLEDyv3aHMBYOaj8LSz8l0gnZdBpMNPG+AWuicsgZqMU8SV9BLWrsb4zPtDdX2gBOm5hoOeN3Az5F3z9t42/cCxs+yf1T6Tm8wZxcpHsy5QjW5Ly0nOVRvNG36JqqPUEl88wDuWxnkPRNlzVXeESNy+Fz/4PqCGuSdolYkrHM8N2i5nCFN5cEvpDsxQ/KiaLmdpvTuPUN2P1/OMn3H5daVvX6WkAIuh1eEAHC7cLjdl86sYvn+3L4wSG9qzf1cpMSEXkLtNxa5xH0iWa84QG9FJ0qB50Qa7RsT0Kpgi7YvD0wiq9lpf6HLTex3i9vModqGv7T6TnSIgw9LKSBY5u5q3zudhceM4hSUjEVVSAng89KiGiS30wgKCo0JPHe8IrRBbQzNs9VIZjCPt38GbligwIy9L70Igre/FJXXXwKKJ7anNYFLoDBJJLmgNIeC3SwPcJZuwysQlCPojsiS/bTOFzpXw90ksZis9LhQe3Q3Q20LUB0qK+hxIwK211AcIZtYaBag8v9QUfXVeagy0J+yVnW1jua0EAM80eelcgviEwFrN6azMNGntD5EbqSPzISiKdDnNQT6STn5UPOrJtPr+YVEaOWC/GP6WJRkXsxYMqIvWGfk8bkImcn7HRYGUU7jcy+7MNt8QBgxxxVj0ALQ68e2phAvbok0EaAFUtwaiGSX4jq1/hxwaLk OjDXkh9q wUqjx/RLjNxOXEictxIpJIlZGLzry9UE46fQJotPZhzhwGfVoW4ZqzubFq4s/GHySr7i1zgVy69wRoRWvvXnacdnUcJiWNlGFpyw7+eYo+7hTpnDyvd2RnJ3nDbYZhQL2d0yXfdIBgCNKdt+CzKHvPP5iyJ3oyi/19k5g3vYSW6KbEW0L4j/p/cPI11DLx/NAN+TBLoxEhPOtzYFtBlvUGFP97D8gMYrGfn9UUi2droiObLhG6s4MHmAa3ps+tZjsOL1UpuzjlYIBaZIJUnLtE3rpJ/1GkgKSeQhaC7BMkgge6wCzkFdxIUxRog== 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: List-Subscribe: List-Unsubscribe: On 10/22/24 23:27, Vlastimil Babka wrote: > On 10/22/24 04:19, Hao Ge wrote: >> On 10/22/24 01:42, Suren Baghdasaryan wrote: >>> On Sun, Oct 20, 2024 at 11:59 PM wrote: >>>> From: Pei Xiao >>>> >>>> 'modprobe slub_kunit',will have a panic.The root cause is that >>>> __kmalloc_cache_noprof was directly ,which resulted in no alloc_tag >>>> being allocated.This caused current->alloc_tag to be null,leading to >>>> a null pointer dereference in alloc_tag_ref_set. >>> I think the root cause of this crash is the bug that is fixed by >>> https://lore.kernel.org/all/20241020070819.307944-1-hao.ge@linux.dev/. >>> Do you get this crash if you apply that fix? >> Yes, this patch has resolved the panic issue. >>>> Here is the log for the panic: >>>> [ 74.779373][ T2158] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 >>>> [ 74.780130][ T2158] Mem abort info: >>>> [ 74.780406][ T2158] ESR = 0x0000000096000004 >>>> [ 74.780756][ T2158] EC = 0x25: DABT (current EL), IL = 32 bits >>>> [ 74.781225][ T2158] SET = 0, FnV = 0 >>>> [ 74.781529][ T2158] EA = 0, S1PTW = 0 >>>> [ 74.781836][ T2158] FSC = 0x04: level 0 translation fault >>>> [ 74.782288][ T2158] Data abort info: >>>> [ 74.782577][ T2158] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 >>>> [ 74.783068][ T2158] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 >>>> [ 74.783533][ T2158] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 >>>> [ 74.784010][ T2158] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000105f34000 >>>> [ 74.784586][ T2158] [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 >>>> [ 74.785293][ T2158] Internal error: Oops: 0000000096000004 [#1] SMP >>>> [ 74.785805][ T2158] Modules linked in: slub_kunit kunit ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute ip6table_nat ip6table_mangle 4 >>>> [ 74.790661][ T2158] CPU: 0 UID: 0 PID: 2158 Comm: kunit_try_catch Kdump: loaded Tainted: G W N 6.12.0-rc3+ #2 >>>> [ 74.791535][ T2158] Tainted: [W]=WARN, [N]=TEST >>>> [ 74.791889][ T2158] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 >>>> [ 74.792479][ T2158] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) >>>> [ 74.793101][ T2158] pc : alloc_tagging_slab_alloc_hook+0x120/0x270 >>>> [ 74.793607][ T2158] lr : alloc_tagging_slab_alloc_hook+0x120/0x270 >>>> >>>> [ 74.794095][ T2158] sp : ffff800084d33cd0 >>>> [ 74.794418][ T2158] x29: ffff800084d33cd0 x28: 0000000000000000 x27: 0000000000000000 >>>> [ 74.795095][ T2158] x26: 0000000000000000 x25: 0000000000000012 x24: ffff80007b30e314 >>>> [ 74.795822][ T2158] x23: ffff000390ff6f10 x22: 0000000000000000 x21: 0000000000000088 >>>> [ 74.796555][ T2158] x20: ffff000390285840 x19: fffffd7fc3ef7830 x18: ffffffffffffffff >>>> [ 74.797283][ T2158] x17: ffff8000800e63b4 x16: ffff80007b33afc4 x15: ffff800081654c00 >>>> [ 74.798011][ T2158] x14: 0000000000000000 x13: 205d383531325420 x12: 5b5d383734363537 >>>> [ 74.798744][ T2158] x11: ffff800084d337e0 x10: 000000000000005d x9 : 00000000ffffffd0 >>>> [ 74.799476][ T2158] x8 : 7f7f7f7f7f7f7f7f x7 : ffff80008219d188 x6 : c0000000ffff7fff >>>> [ 74.800206][ T2158] x5 : ffff0003fdbc9208 x4 : ffff800081edd188 x3 : 0000000000000001 >>>> [ 74.800932][ T2158] x2 : 0beaa6dee1ac5a00 x1 : 0beaa6dee1ac5a00 x0 : ffff80037c2cb000 >>>> [ 74.801656][ T2158] Call trace: >>>> [ 74.801954][ T2158] alloc_tagging_slab_alloc_hook+0x120/0x270 >>>> [ 74.802494][ T2158] __kmalloc_cache_noprof+0x148/0x33c >>>> [ 74.802976][ T2158] test_kmalloc_redzone_access+0x4c/0x104 [slub_kunit] >>>> [ 74.803607][ T2158] kunit_try_run_case+0x70/0x17c [kunit] >>>> [ 74.804124][ T2158] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] >>>> [ 74.804768][ T2158] kthread+0x10c/0x118 >>>> [ 74.805141][ T2158] ret_from_fork+0x10/0x20 >>>> [ 74.805540][ T2158] Code: b9400a80 11000400 b9000a80 97ffd858 (f94012d3) >>>> [ 74.806176][ T2158] SMP: stopping secondary CPUs >>>> [ 74.808130][ T2158] Starting crashdump kernel... >>>> >>> CC'ing Vlastimil. >>> This patch essentially reverts Vlastimil's "mm, slab: don't wrap >>> internal functions with alloc_hooks()" change. Please check why that >>> change was needed before proceeding. >>> If this change is indeed needed, please add: >> Hi Suren and Vlastimil >> >> In fact, besides the panic, there is also a warning here due to directly >> invoking__kmalloc_cache_noprof >> >> Regarding this, do you have any suggestions? >> >> [58162.947016] WARNING: CPU: 2 PID: 6210 at >> ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c >> [58162.957721] Call trace: >> [58162.957919]  alloc_tagging_slab_alloc_hook+0x268/0x27c >> [58162.958286]  __kmalloc_cache_noprof+0x14c/0x344 >> [58162.958615]  test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] >> [58162.959045]  kunit_try_run_case+0x74/0x184 [kunit] >> [58162.959401]  kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] >> [58162.959841]  kthread+0x10c/0x118 >> [58162.960093]  ret_from_fork+0x10/0x20 >> [58162.960363] ---[ end trace 0000000000000000 ]--- > I see. > The kunit test is the only user of __kmalloc_cache_noprof outside of kmalloc() > itself so it's not worth defining again a wrapper for everyone, how about just > wrapping the two callsites? > > --- a/lib/slub_kunit.c > +++ b/lib/slub_kunit.c > @@ -141,7 +141,7 @@ static void test_kmalloc_redzone_access(struct kunit *test) > { > struct kmem_cache *s = test_kmem_cache_create("TestSlub_RZ_kmalloc", 32, > SLAB_KMALLOC|SLAB_STORE_USER|SLAB_RED_ZONE); > - u8 *p = __kmalloc_cache_noprof(s, GFP_KERNEL, 18); > + u8 *p = alloc_hooks(__kmalloc_cache_noprof(s, GFP_KERNEL, 18)); > > kasan_disable_current(); > > @@ -199,7 +199,7 @@ static void test_krealloc_redzone_zeroing(struct kunit *test) > struct kmem_cache *s = test_kmem_cache_create("TestSlub_krealloc", 64, > SLAB_KMALLOC|SLAB_STORE_USER|SLAB_RED_ZONE); > > - p = __kmalloc_cache_noprof(s, GFP_KERNEL, 48); > + p = alloc_hooks(__kmalloc_cache_noprof(s, GFP_KERNEL, 48)); > memset(p, 0xff, 48); > > kasan_disable_current(); > Hi  Vlastimil I agree with your point of view, thank you for you and Suren's help and suggestion. Best regards Hao