All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: John Thomson <git@johnthomson.fastmail.com.au>
Cc: "Sergio Paracuellos" <sergio.paracuellos@gmail.com>,
	"John Crispin" <john@phrozen.org>,
	"Arınç ÜNAL" <arinc.unal@arinc9.com>,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] mips: ralink: mt7621: do not use kzalloc too early
Date: Thu, 1 Dec 2022 14:33:44 +0100	[thread overview]
Message-ID: <20221201133344.GC10560@alpha.franken.de> (raw)
In-Reply-To: <20221114015658.2873120-4-git@johnthomson.fastmail.com.au>

On Mon, Nov 14, 2022 at 11:56:58AM +1000, John Thomson wrote:
> With CONFIG_SLUB=y, following commit 6edf2576a6cc ("mm/slub: enable
> debugging memory wasting of kmalloc") mt7621 failed to boot very early,
> without showing any console messages.
> This exposed the pre-existing bug of mt7621.c using kzalloc before normal
> memory management was available.
> Prior to this slub change, there existed the unintended protection against
> "kmem_cache *s" being NULL as slab_pre_alloc_hook() happened to
> return NULL and bailed out of slab_alloc_node().
> This allowed mt7621 prom_soc_init to fail in the soc_dev_init kzalloc,
> but continue booting without the SOC_BUS driver device registered.
> 
> Console output from a DEBUG_ZBOOT vmlinuz kernel loading,
> with mm/slub modified to warn on kmem_cache zero or null:
> 
> 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
> 
> Allowing soc_device_register to work exposed oops in the mt7621 phy pci,
> and pci controller drivers from soc_device_match_attr, due to missing
> sentinels in the quirks tables. These were fixed with:
> commit 819b885cd886 ("phy: ralink: mt7621-pci: add sentinel to quirks
> table")
> not yet applied ("PCI: mt7621: add sentinel to quirks table")
> 
> Link: https://lore.kernel.org/linux-mm/becf2ac3-2a90-4f3a-96d9-a70f67c66e4a@app.fastmail.com/
> Fixes: 71b9b5e0130d ("MIPS: ralink: mt7621: introduce 'soc_device' initialization")
> Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
> ---
>  arch/mips/ralink/mt7621.c | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)

applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

      reply	other threads:[~2022-12-01 13:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-14  1:56 [PATCH 0/3] mips: ralink: mt7621: fix kzalloc too early John Thomson
2022-11-14  1:56 ` [PATCH 1/3] mips: ralink: mt7621: define MT7621_SYSC_BASE with __iomem John Thomson
2022-12-01 13:32   ` Thomas Bogendoerfer
2022-11-14  1:56 ` [PATCH 2/3] mips: ralink: mt7621: soc queries and tests as functions John Thomson
2022-12-01 13:33   ` Thomas Bogendoerfer
2022-11-14  1:56 ` [PATCH 3/3] mips: ralink: mt7621: do not use kzalloc too early John Thomson
2022-12-01 13:33   ` Thomas Bogendoerfer [this message]

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=20221201133344.GC10560@alpha.franken.de \
    --to=tsbogend@alpha.franken.de \
    --cc=arinc.unal@arinc9.com \
    --cc=git@johnthomson.fastmail.com.au \
    --cc=john@phrozen.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=sergio.paracuellos@gmail.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.