Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 1 Nov 2022 15:57:46 +0800
From:   Feng Tang <feng.tang@intel.com>
To:     John Thomson <lists@johnthomson.fastmail.com.au>
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>,
        Hyeonggon Yoo <42.hyeyoo@gmail.com>,
        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>,
        <linux-mips@vger.kernel.org>
Subject: Re: [PATCH v6 1/4] mm/slub: enable debugging memory wasting of
 kmalloc
Message-ID: <Y2DReuPHZungAGsU@feng-clx>
References: <20220913065423.520159-1-feng.tang@intel.com>
 <20220913065423.520159-2-feng.tang@intel.com>
 <becf2ac3-2a90-4f3a-96d9-a70f67c66e4a@app.fastmail.com>
 <af2ba83d-c3f4-c6fb-794e-c2c7c0892c44@suse.cz>
 <Y180l6zUnNjdCoaE@feng-clx>
 <c4285caf-277c-45fd-8fc7-8a1d61685ce8@app.fastmail.com>
 <Y1+0sbQ3R4DB46NX@feng-clx>
 <9b71ae3e-7f53-4c9e-90c4-79d3d649f94c@app.fastmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9b71ae3e-7f53-4c9e-90c4-79d3d649f94c@app.fastmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?l+qgPhplE+K9mYy+8IwfgB2GrWBaXneQSj5P1LzWUfSVFPJBzEtg+4/qTeRd?=
 =?us-ascii?Q?Vs9HPB/z/U9LklfGAcocFn5JU0gJ4nWsvbTuBC6JB0WBkP6lWI8QcIuV5sHg?=
 =?us-ascii?Q?i9oiSe16oboG/kHMQpfjB0E3iBbbntcCwZ/eKkeyeYnZ6Y9DD4BVCkhLtB+T?=
 =?us-ascii?Q?WJhi6RV5G97iyfWzf73hjh1itn4p7bFaunt6Z/9MHiEp6+xmm617OZJW3smK?=
 =?us-ascii?Q?dtvFKyOxRflEN+trUJGB7FYNqgz+zkj5v/KOjZOCtoUgqdcba8HwwP4bdRxD?=
 =?us-ascii?Q?CfUFOnHhRPEnRoBRhlOr10I2mq287bnKcZRIfYii1aSNxj0BJcOJAgZ6P4Mh?=
 =?us-ascii?Q?/ycS889EW0cKBcRHRaastvUGU0XH1vYeiHk/xP+hi3vQocfxdObrpLDhux0F?=
 =?us-ascii?Q?4zM/iu5L4T32s2PzohGYN8jSrMQEGn4oMuxpWHigbayhSQR+4d+/Shv+MmHa?=
 =?us-ascii?Q?qri42B6X2e7rIhaYWXljdMp2iPuKZCql/p/k7n9FCEK7uLpi4G64lVAOS5Yg?=
 =?us-ascii?Q?TAeM98pvXphNyLudBnUKWNWzVy5g/1JYLjFQjlykvXcp25LMgpsLsyYu7KyQ?=
 =?us-ascii?Q?OobJuBV5jCwBgFm2F7P6shTcxqaQKQ4eLwOHR6ckRuvlfD/PxOz3ZepnCmKl?=
 =?us-ascii?Q?vE5VcqPBE0tGBeUiJixQLSptRf0HZjnk55GMPJa4dU4nDitrgdA5vwWCcdSx?=
 =?us-ascii?Q?IRl7l0lErJUlUKMwL4cw2heOzBD/48NBHGJ/o6HfvugP4QTjMpvt90DbpwDT?=
 =?us-ascii?Q?gibPd1hmNc6dPUFBF5fTyLdjW6U+nxULJOhrb3Uh29YGVouiwwz7MOt7ba10?=
 =?us-ascii?Q?mNneKyQt1SGx+jh9m33x7hz3ICPogfyKlI5twUjmDzK51Nx4hzH3Gqo3MMFb?=
 =?us-ascii?Q?yIxXOZLZq1vZxvDQDNQpfhBmj+slOrRmCHyTE1A1lzde3ANfNFKSueVqHymb?=
 =?us-ascii?Q?qi/dvje94XxBq3UJe3+0QG8Qm/BEYauUmitoXJnAGjmY8HJPbtK3fmNxo1zV?=
 =?us-ascii?Q?88mine/jAcXpEeijcLFlCgPRdGpj1zwujTaaG1nbjY9Ru/c0K69RU8uSczKZ?=
 =?us-ascii?Q?kDbOsVouEDK6ub2rPBZ0SbsTTyqdaVg0j/IxqpP3JW4i1NCKmkWmvngEmTfP?=
 =?us-ascii?Q?MfR0i8Wl3lCYoFw2JyAQhUhL93fdLz7QFyfjlM3w5fcftGsh6srmF05XCWEJ?=
 =?us-ascii?Q?bqQWNPfpqZpS6FK/uBlxdUt3hpN2oiw0coiICFrb8PU4o39yHwNI7JRfmmQt?=
 =?us-ascii?Q?lRShYe+WUP0KoFt3FKqhKNcVv89stjjR+RPUrgKfUBv+au0WqBpyRwAe1fP4?=
 =?us-ascii?Q?wfk7zmwHkE7y/jWhK3qanAiTl45uiJQCgfZgbv1XDs2EkiRAAItmii9wwCaR?=
 =?us-ascii?Q?1dv4HMYeItOXDqCYzITFWbWqcXzPZ3m65OILn2fNdnaGQcHuvOSyM2ud9cU8?=
 =?us-ascii?Q?UVkxedamRxDqzBuSx2k8HQRy9HytjT7F1IurQS5RIkOuYCB1zAjsuGztQrbx?=
 =?us-ascii?Q?kaqsUIjdMO1Qmr1OqYuUIJuMHZCdTeY5hh2IVU0SaiXEu8iuUXMhqk++c6/e?=
 =?us-ascii?Q?GuOzJjSUdTp66FxWZB8XOFgr6/JOmZNAWF8ozzjB?=
X-MS-Exchange-CrossTenant-Network-Message-Id: bebba90f-a2a1-42ec-d960-08dabbdecc9e
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2022 07:58:02.2549
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: +Spq6KwKs+rl50bZs28kLdQhR+x45aY7uSNJdp8r6YEGxTFv/LDaHiyif1QNCXwYEdxcfKvFZUOwOrbQsSW/cw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB6913
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,
        SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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/

On Tue, Nov 01, 2022 at 12:18:19AM +0000, John Thomson wrote:
> > As I can't reproduce it locally yet, could you help try 3 tests separately:
> > * change the O2/O3 compile option to O1
> > * try the attached 0001 patch (which cut part of commit)
> > * try attached 0001+0002 patch
> 
> None of these changed my outcome.

0001 patch chops off most of the functional changes, and it still
fails. I'm wondering if it is related to the function arguments'
passing, I noticed this is a 32 bits MIPS platform (from your config)   

> I also tried compiling the same linux tree & config with the Bootlin toolchain
> (mipsel-buildroot-linux-gnu-gcc.br_real (Buildroot 2021.11-4428-g6b6741b) 12.2.0)
> with the same results.
> I will look into finding or building a mips clang toolchain.
 
Yes, Hyeonggon's suggestion makes sense, different compiler may
show some difference.

> No JTAG capability to debug, sorry.
> 
> I get the same outcome with either the ZBOOT vmlinuz, or vmlinux
> 
> Same happening with 6.1-rc3
> 
> 
> After some blind poking around changing (how much of the commit affected) mm/slub.c,
> I may have got lucky. it appears as though this is all I need to boot:
> (against 6.1-rc3), and with the Bootlin toolchain. Will test my other build system as well.
> 
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3276,7 +3276,7 @@ static void *__slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
>         c = slub_get_cpu_ptr(s->cpu_slab);
>  #endif
>  
> -       p = ___slab_alloc(s, gfpflags, node, addr, c, orig_size);
> +       p = ___slab_alloc(s, gfpflags, node, addr, c, 0);

___slab_alloc()'s argument number has been changed from 5 to 6, and
some others from 4 to 5.

Thanks,
Feng


>  #ifdef CONFIG_PREEMPT_COUNT
>         slub_put_cpu_ptr(s->cpu_slab);
>  #endif