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@xxxxxxxxxxxxxxxx/ 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
