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 4FC38FA373D for ; Tue, 1 Nov 2022 09:31:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CED466B0073; Tue, 1 Nov 2022 05:31:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9DD06B0074; Tue, 1 Nov 2022 05:31:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B656F8E0001; Tue, 1 Nov 2022 05:31:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A616B6B0073 for ; Tue, 1 Nov 2022 05:31:58 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 47A5AAAA27 for ; Tue, 1 Nov 2022 09:31:58 +0000 (UTC) X-FDA: 80084356716.22.45B7D62 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by imf11.hostedemail.com (Postfix) with ESMTP id D560A40039 for ; Tue, 1 Nov 2022 09:31:57 +0000 (UTC) Received: by mail-pf1-f170.google.com with SMTP id v28so12782187pfi.12 for ; Tue, 01 Nov 2022 02:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=O9VIRZCiJ5gmKs+BRWjCnVIEMt23r/xHSISakg/E7V4=; b=a4+Nyl0dzTg6tWdyT+EPhpvC0t3GWT2WCwkIZyKpj+WPfyeEM72uxzp+gfBgHnCZwf rKd8jocwcm3msqO6mv3LB8Q+RoALCNejtj3YC7DJY1Fdltijdw0bjozyeDsjDa7H6/fQ w5WnfmgBDWKK2htESdGgUcEfa7MttbG8NKlQv6gX2qZtVTBJZ/RCGk8YjPalnlMWM6me MTbYsJLZ16ZwYAADfHnM3pMJajh4OZKv4EtQa39syLhJHc6hDbx+VkpjE3VFB+B+H+c4 IBcfwNTZV6Keyxn+erezCJVoGvI8lBcDefORS8jeCtjzq3ZLfGnrZM5wD/P4daLJOpcE L78Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=O9VIRZCiJ5gmKs+BRWjCnVIEMt23r/xHSISakg/E7V4=; b=rHBxxkuujsTJ1DgB5j9aE3+JAfIxFEmkVWscy1HX9VeKTcw5ZsoAlHkqJ7NydNskXL YbnvIciqGtfaXjxJuPgWjOCf52OjEilTBmxRVVkeTg1LGq3Tclk40p119ECxSUmODtIg 3x3bqM1tRnd7Dy3oEK1HDsfFwh83SOYPohy5o9Z57vAH39v6l+AzIrQ9ahR9/3fmu/Ct B1OIu0SXwwiI0ellX9cmu5TnY1zGq/k2gqRdX/DL9++Of9/MLurJG+E4rerAVHI/Wuzz RH39R6DZ7B1GONP59b4X/Huvx9rXyc7HWpdaFExl8OXDwFtI+n0jSXzzf5uxsNWpFsDF UxUQ== X-Gm-Message-State: ACrzQf1CmyN4g3xFWZZ+XoB26L50Jt1Ec+RIRW9qVZHE9JlOM40J8GlM eru6zMKyROeMWIMCFP6hMB0= X-Google-Smtp-Source: AMsMyM7t0mLLMlLPTydO72rFm96lHi0wTH43Oka0AuC5lLv5H2McpH32BH2XxFe0sHZjMKTDSCYrAg== X-Received: by 2002:aa7:88d4:0:b0:56c:ae9d:6fdf with SMTP id k20-20020aa788d4000000b0056cae9d6fdfmr18949920pff.41.1667295116599; Tue, 01 Nov 2022 02:31:56 -0700 (PDT) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id e25-20020aa79819000000b0056bc1d7816dsm6216189pfl.99.2022.11.01.02.31.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Nov 2022 02:31:55 -0700 (PDT) Date: Tue, 1 Nov 2022 18:31:47 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: John Thomson Cc: Feng Tang , Vlastimil Babka , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Dmitry Vyukov , Jonathan Corbet , Andrey Konovalov , "Hansen, Dave" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "kasan-dev@googlegroups.com" , Robin Murphy , John Garry , Kefeng Wang , Thomas Bogendoerfer , linux-mips@vger.kernel.org Subject: Re: [PATCH v6 1/4] mm/slub: enable debugging memory wasting of kmalloc Message-ID: References: <20220913065423.520159-1-feng.tang@intel.com> <20220913065423.520159-2-feng.tang@intel.com> <9b71ae3e-7f53-4c9e-90c4-79d3d649f94c@app.fastmail.com> <53b53476-bb1e-402e-9f65-fd7f0ecf94c2@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53b53476-bb1e-402e-9f65-fd7f0ecf94c2@app.fastmail.com> ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=a4+Nyl0d; spf=pass (imf11.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667295117; a=rsa-sha256; cv=none; b=2e0+VbtziIx6AWrrqkiYwLitHi0/HPUQ7Oa94u/OVbltW68cv73CagO1C5wgovvtJPNYV1 DDfFI+9EssUuk3c9Jn1aaDH42yCMneJJkax3T1mWQ7Uw5eeAwudVyLOIDs37Y5GuVvSCs7 H/OUyP7uf3+7sIEM8QV8QMrkxokTEjE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667295117; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=O9VIRZCiJ5gmKs+BRWjCnVIEMt23r/xHSISakg/E7V4=; b=Ynv93NXTbQQTO1m0F7ylrdDJSMz3IHBtW/7J3GJa2x72Hz3/kraGLSayXpyfPsI1OJmHPz YI2yQkyl+ZBUeXqN4ziZatrpNLRioxFWealxGTs4LJpaNBmwT9OvfjEsC1V8vZWnqJI6UX gjiw8KlvqI9/iRJnrceGeduMcNqG2tM= X-Rspam-User: X-Rspamd-Queue-Id: D560A40039 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=a4+Nyl0d; spf=pass (imf11.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: jhmwbbyqph5c4tteey5mcemeer8at8c9 X-Rspamd-Server: rspam10 X-HE-Tag: 1667295117-890225 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 Tue, Nov 01, 2022 at 09:20:21AM +0000, John Thomson wrote: > On Tue, 1 Nov 2022, at 07:57, Feng Tang wrote: > > Hi Thomson, > > > > Thanks for testing! > > > > + mips maintainer and mail list. The original report is here > > > > https://lore.kernel.org/lkml/becf2ac3-2a90-4f3a-96d9-a70f67c66e4a@app.fastmail.com/ > > I am guessing my issue comes from __kmem_cache_alloc_lru accessing s->object_size when (kmem_cache) s is NULL? > If that is the case, this change is not to blame, it only exposes the issue? > > I get the following dmesg (note very early NULL kmem_cache) with the below change atop v6.1-rc3: > > transfer started ......................................... transfer ok, time=2.02s > setting up elf image... OK > jumping to kernel code > zimage at: 80B842A0 810B4EFC > > 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) #61 SMP Tue Nov 1 18:04:13 AEST 2022 > [ 0.000000] slub: kmem_cache_alloc called with kmem_cache: 0x0 > [ 0.000000] slub: __kmem_cache_alloc_lru called with kmem_cache: 0x0 > [ 0.000000] SoC Type: MediaTek MT7621 ver:1 eco:3 > [ 0.000000] printk: bootconsole [early0] enabled > [ 0.000000] CPU0 revision is: 0001992f (MIPS 1004Kc) > [ 0.000000] MIPS: machine is MikroTik RouterBOARD 760iGS > > normal boot > > > diff --git a/mm/slub.c b/mm/slub.c > index 157527d7101b..10fcdf2520d2 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -3410,7 +3410,13 @@ 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 (IS_ERR_OR_NULL(s)) { > + pr_warn("slub: __kmem_cache_alloc_lru called with kmem_cache: %pSR\n", s); > + ret = slab_alloc(s, lru, gfpflags, _RET_IP_, 0); > + } else { > + ret = slab_alloc(s, lru, gfpflags, _RET_IP_, s->object_size); > + } > > trace_kmem_cache_alloc(_RET_IP_, ret, s, gfpflags, NUMA_NO_NODE); > > @@ -3419,6 +3425,8 @@ void *__kmem_cache_alloc_lru(struct kmem_cache *s, struct list_lru *lru, > > void *kmem_cache_alloc(struct kmem_cache *s, gfp_t gfpflags) > { > + if (IS_ERR_OR_NULL(s)) > + pr_warn("slub: kmem_cache_alloc called with kmem_cache: %pSR\n", s); > return __kmem_cache_alloc_lru(s, NULL, gfpflags); > } > EXPORT_SYMBOL(kmem_cache_alloc); > @@ -3426,6 +3434,8 @@ EXPORT_SYMBOL(kmem_cache_alloc); > void *kmem_cache_alloc_lru(struct kmem_cache *s, struct list_lru *lru, > gfp_t gfpflags) > { > + if (IS_ERR_OR_NULL(s)) > + pr_warn("slub: __kmem_cache_alloc_lru called with kmem_cache: %pSR\n", s); > return __kmem_cache_alloc_lru(s, lru, gfpflags); > } > EXPORT_SYMBOL(kmem_cache_alloc_lru); > > > Any hints on where kmem_cache_alloc would be being called from this early? > I will start looking from /init/main.c around pr_notice("%s", linux_banner); Great. Would you try calling dump_stack(); when we observed s == NULL? That would give more information about who passed s == NULL to these functions. -- Thanks, Hyeonggon