From: Hao Ge <hao.ge@linux.dev>
To: Vlastimil Babka <vbabka@suse.cz>,
Suren Baghdasaryan <surenb@google.com>,
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
Subject: Re: [PATCH] slub/slub_kunit:fix a panic due to __kmalloc_cache_noprof incorretly use
Date: Wed, 23 Oct 2024 09:47:25 +0800 [thread overview]
Message-ID: <32f70816-1678-d6ab-0db1-6412ff7a7333@linux.dev> (raw)
In-Reply-To: <e283001d-c6f4-49f8-aca6-4e9826d45c9a@suse.cz>
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 <xiaopeitux@foxmail.com> wrote:
>>>> From: Pei Xiao <xiaopei01@kylinos.cn>
>>>>
>>>> '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
next prev parent reply other threads:[~2024-10-23 1:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 6:59 [PATCH] slub/slub_kunit:fix a panic due to __kmalloc_cache_noprof incorretly use xiaopeitux
2024-10-21 17:42 ` Suren Baghdasaryan
2024-10-22 2:19 ` Hao Ge
2024-10-22 15:27 ` Vlastimil Babka
2024-10-23 1:47 ` Hao Ge [this message]
2024-10-23 1:58 ` Suren Baghdasaryan
2024-10-23 6:21 ` [PATCH] slub_kunit:fix a WARNING " Pei Xiao
2024-10-23 8:00 ` Vlastimil Babka
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=32f70816-1678-d6ab-0db1-6412ff7a7333@linux.dev \
--to=hao.ge@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=gehao@kylinso.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=xiaopei01@kylinos.cn \
--cc=xiaopeitux@foxmail.com \
--cc=xiongxin@kylinos.cn \
--cc=yuzhao@google.com \
/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: link
Be 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.