linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "John Thomson" <lists@johnthomson.fastmail.com.au>
To: "Feng Tang" <feng.tang@intel.com>, "Hyeonggon Yoo" <42.hyeyoo@gmail.com>
Cc: "Vlastimil Babka" <vbabka@suse.cz>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Christoph Lameter" <cl@linux.com>,
	"Pekka Enberg" <penberg@kernel.org>,
	"David Rientjes" <rientjes@google.com>,
	"Joonsoo Kim" <iamjoonsoo.kim@lge.com>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Andrey Konovalov" <andreyknvl@gmail.com>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"John Garry" <john.garry@huawei.com>,
	"Kefeng Wang" <wangkefeng.wang@huawei.com>,
	"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
	"John Crispin" <john@phrozen.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>
Subject: Re: [PATCH v6 1/4] mm/slub: enable debugging memory wasting of kmalloc
Date: Tue, 01 Nov 2022 19:39:13 +0000	[thread overview]
Message-ID: <70002fbe-34ec-468e-af67-97e4bf97819b@app.fastmail.com> (raw)
In-Reply-To: <Y2ElURkvmGD5csMc@feng-clx>



On Tue, 1 Nov 2022, at 13:55, Feng Tang wrote:
> On Tue, Nov 01, 2022 at 06:42:23PM +0800, Hyeonggon Yoo wrote:
>> setup_arch() is too early to use slab allocators.
>> I think slab received NULL pointer because kmalloc is not initialized.
>> 
>> It seems arch/mips/ralink/mt7621.c is using slab too early.
>
> Cool! it is finally root caused :) Thanks!
>
> The following patch should solve it and give it a warning message, though
> I'm not sure if there is other holes.  
>
> Thanks,
> Feng
>
> ---
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 33b1886b06eb..429c21b7ecbc 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1043,7 +1043,14 @@ size_t __ksize(const void *object)
>  #ifdef CONFIG_TRACING
>  void *kmalloc_trace(struct kmem_cache *s, gfp_t gfpflags, size_t size)
>  {
> -	void *ret = __kmem_cache_alloc_node(s, gfpflags, NUMA_NO_NODE,
> +	void *ret;
> +
> +	if (unlikely(ZERO_OR_NULL_PTR(s))) {
> +		WARN_ON_ONCE(1);
> +		return s;
> +	}
> +
> +	ret = __kmem_cache_alloc_node(s, gfpflags, NUMA_NO_NODE,
>  					    size, _RET_IP_);
> 
>  	trace_kmalloc(_RET_IP_, ret, size, s->size, gfpflags, NUMA_NO_NODE);
> diff --git a/mm/slub.c b/mm/slub.c
> index 157527d7101b..85d24bb6eda7 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3410,8 +3410,14 @@ static __always_inline
>  void *__kmem_cache_alloc_lru(struct kmem_cache *s, struct list_lru *lru,
>  			     gfp_t gfpflags)
>  {
> -	void *ret = slab_alloc(s, lru, gfpflags, _RET_IP_, s->object_size);
> +	void *ret;
> 
> +	if (unlikely(ZERO_OR_NULL_PTR(s))) {
> +		WARN_ON_ONCE(1);
> +		return s;
> +	}
> +
> +	ret = slab_alloc(s, lru, gfpflags, _RET_IP_, s->object_size);
>  	trace_kmem_cache_alloc(_RET_IP_, ret, s, gfpflags, NUMA_NO_NODE);
> 
>  	return ret;

Yes, thank you, that patch atop v6.1-rc3 lets me boot, and shows the warning and stack dump.
Will you submit that, or how do we want to proceed?

transfer started ......................................... transfer ok, time=2.11s
setting up elf image... OK
jumping to kernel code
zimage at:     80B842A0 810B4BC0

Uncompressing Linux at load address 80001000

Copy device tree to address  80B80EE0

Now, booting the kernel...

[    0.000000] Linux version 6.1.0-rc3+ (john@john) (mipsel-buildroot-linux-gnu-gcc.br_real (Buildroot 2021.11-4428-g6b6741b) 12.2.0, GNU ld (GNU Binutils) 2.39) #73 SMP Wed Nov  2 05:10:01 AEST 2022
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at mm/slub.c:3416 kmem_cache_alloc+0x5a4/0x5e8
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.1.0-rc3+ #73
[    0.000000] Stack : 810fff78 80084d98 00000000 00000004 00000000 00000000 80889d04 80c90000
[    0.000000]         80920000 807bd328 8089d368 80923bd3 00000000 00000001 80889cb0 00000000
[    0.000000]         00000000 00000000 807bd328 8084bcb1 00000002 00000002 00000001 6d6f4320
[    0.000000]         00000000 80c97d3d 80c97d68 fffffffc 807bd328 00000000 00000000 00000000
[    0.000000]         00000000 a0000000 80910000 8110a0b4 00000000 00000020 80010000 80010000
[    0.000000]         ...
[    0.000000] Call Trace:
[    0.000000] [<80008260>] show_stack+0x28/0xf0
[    0.000000] [<8070c958>] dump_stack_lvl+0x60/0x80
[    0.000000] [<8002e184>] __warn+0xc4/0xf8
[    0.000000] [<8002e210>] warn_slowpath_fmt+0x58/0xa4
[    0.000000] [<801c0fac>] kmem_cache_alloc+0x5a4/0x5e8
[    0.000000] [<8092856c>] prom_soc_init+0x1fc/0x2b4
[    0.000000] [<80928060>] prom_init+0x44/0xf0
[    0.000000] [<80929214>] setup_arch+0x4c/0x6a8
[    0.000000] [<809257e0>] start_kernel+0x88/0x7c0
[    0.000000] 
[    0.000000] ---[ end trace 0000000000000000 ]---
[    0.000000] SoC Type: MediaTek MT7621 ver:1 eco:3
[    0.000000] printk: bootconsole [early0] enabled

Thank you for working through this with me.
I will try to address the root cause in mt7621.c.
It looks like other arch/** soc_device_register users use postcore_initcall, device_initcall,
or the ARM DT_MACHINE_START .init_machine. A quick hack to use postcore_initcall in mt7621
avoided this zero ptr kmem_cache passed to kmem_cache_alloc_lru.


Thanks,

-- 
  John Thomson


  reply	other threads:[~2022-11-01 19:40 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-13  6:54 [PATCH v6 0/4] mm/slub: some debug enhancements for kmalloc Feng Tang
2022-09-13  6:54 ` [PATCH v6 1/4] mm/slub: enable debugging memory wasting of kmalloc Feng Tang
2022-09-23 11:43   ` Vlastimil Babka
2022-09-24  7:08     ` Feng Tang
2022-10-30 19:23   ` John Thomson
2022-10-30 21:30     ` Vlastimil Babka
2022-10-31  2:36       ` Feng Tang
2022-10-31 10:05         ` John Thomson
2022-10-31 11:36           ` Hyeonggon Yoo
2022-10-31 11:42           ` Feng Tang
2022-11-01  0:18             ` John Thomson
2022-11-01  2:41               ` John Thomson
2022-11-01  7:57               ` Feng Tang
2022-11-01  9:20                 ` John Thomson
2022-11-01  9:31                   ` Hyeonggon Yoo
2022-11-01 10:33                     ` John Thomson
2022-11-01 10:42                       ` Hyeonggon Yoo
2022-11-01 13:55                         ` Feng Tang
2022-11-01 19:39                           ` John Thomson [this message]
2022-11-02  6:08                             ` Feng Tang
2022-11-02  7:16                               ` Hyeonggon Yoo
2022-11-03  7:18                                 ` Feng Tang
2022-11-03  7:45                                   ` John Thomson
2022-11-03  8:16                                     ` Feng Tang
2022-11-02  8:22                       ` Vlastimil Babka
2022-11-03  5:54                         ` Feng Tang
2022-11-03  8:33                           ` Vlastimil Babka
2022-11-03 14:16                             ` Feng Tang
2022-11-03 14:36                               ` Hyeonggon Yoo
2022-11-03 16:57                                 ` Vlastimil Babka
2022-11-03 17:35                                   ` Vlastimil Babka
2022-11-04  3:52                                     ` Feng Tang
2022-09-13  6:54 ` [PATCH v6 2/4] mm/slub: only zero the requested size of buffer for kzalloc Feng Tang
2022-09-26 19:11   ` Andrey Konovalov
2022-09-26 20:15     ` Kees Cook
2022-09-27  1:22       ` Feng Tang
2022-09-27  2:42     ` Feng Tang
2022-10-13 14:00       ` Andrey Konovalov
2022-10-14  5:59         ` Feng Tang
2022-09-13  6:54 ` [PATCH v6 3/4] mm: kasan: Add free_meta size info in struct kasan_cache Feng Tang
2022-09-20 19:20   ` Andrey Konovalov
2022-09-21 12:02     ` Feng Tang
2022-09-24 18:05       ` Andrey Konovalov
2022-09-25 11:26         ` Feng Tang
2022-09-25 16:31           ` Andrey Konovalov
2022-09-27  3:03             ` Feng Tang
2022-09-13  6:54 ` [PATCH v6 4/4] mm/slub: extend redzone check to extra allocated kmalloc space than requested Feng Tang
2022-09-13  8:53   ` Hyeonggon Yoo

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=70002fbe-34ec-468e-af67-97e4bf97819b@app.fastmail.com \
    --to=lists@johnthomson.fastmail.com.au \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=cl@linux.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@intel.com \
    --cc=dvyukov@google.com \
    --cc=feng.tang@intel.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=john.garry@huawei.com \
    --cc=john@phrozen.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthias.bgg@gmail.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=robin.murphy@arm.com \
    --cc=roman.gushchin@linux.dev \
    --cc=tsbogend@alpha.franken.de \
    --cc=vbabka@suse.cz \
    --cc=wangkefeng.wang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox