* Re: Random warning dump during init.
2018-07-11 18:17 Random warning dump during init Rob Landley
2018-07-12 14:53 ` Rob Landley
@ 2018-07-12 19:59 ` Geert Uytterhoeven
2018-07-12 20:52 ` Matthew Wilcox
2 siblings, 0 replies; 4+ messages in thread
From: Geert Uytterhoeven @ 2018-07-12 19:59 UTC (permalink / raw)
To: linux-sh
CC willy
On Thu, Jul 12, 2018 at 4:55 PM Rob Landley <rob@landley.net> wrote:
> On 07/11/2018 01:17 PM, Rob Landley wrote:
> > Building commit d0fbad0aec1d (from July 2) I hit this, and I confirmed today's
> > pull is still doing it. (It's my mkroot sh4 target built with musl-cross-make,
> > booting under qemu.)
> >
> > NET: Registered protocol family 17
> > Freeing unused kernel memory: 116K
> > This architecture does not have kernel memory protection.
> > WARNING: CPU: 0 PID: 1 at mm/slub.c:2412 ___slab_alloc.constprop.34+0x196/0x288
> >
> > CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0-rc3 #1
> > PC is at ___slab_alloc.constprop.34+0x196/0x288
> > PR is at __slab_alloc.constprop.33+0x2a/0x4c
> > PC : 8c09ada2 SP : 8f829ea8 SR : 400080f0
> > TEA : c0001240
> > R0 : 8c09ac0c R1 : 8c01cc54 R2 : 8ff750d0 R3 : 00000000
> > R4 : 8f802780 R5 : 006080c0 R6 : 8c01d79c R7 : 8ff750d0
> > R8 : 8c011bd8 R9 : 8ff750d0 R10 : 8f802780 R11 : 00008000
> > R12 : 8c01d79c R13 : 006080c0 R14 : 8f8027fc
> > MACH: 00000205 MACL: 0ae4849d GBR : 00000000 PR : 8c09aebe
> >
> > Call trace:
> > [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> > [<(ptrval)>] __slab_alloc.constprop.33+0x2a/0x4c
> > [<(ptrval)>] arch_local_save_flags+0x0/0x8
> > [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> > [<(ptrval)>] mm_init.isra.6+0xb4/0x104
> > [<(ptrval)>] kmem_cache_alloc+0x9c/0xf4
> > [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> > [<(ptrval)>] mm_init.isra.6+0xb4/0x104
> > [<(ptrval)>] mm_init.isra.6+0xb4/0x104
> > [<(ptrval)>] __do_execve_file+0x1da/0x5bc
> > [<(ptrval)>] kmem_cache_alloc+0x0/0xf4
> > [<(ptrval)>] getname_kernel+0x1e/0xc8
> > [<(ptrval)>] do_execve+0x16/0x24
> > [<(ptrval)>] arch_local_save_flags+0x0/0x8
> > [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> > [<(ptrval)>] printk+0x0/0x24
> > [<(ptrval)>] kernel_init+0x34/0xec
> > [<(ptrval)>] ret_from_kernel_thread+0xc/0x14
> > [<(ptrval)>] schedule_tail+0x0/0x54
> > [<(ptrval)>] kernel_init+0x0/0xec
> >
> > ---[ end trace 547fc2facfcadcaf ]---
> > 8139cp 0000:00:02.0 eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
> > Type exit when done.
> > / #
>
> I bisected it to:
>
> commit 128227e7fe4087b60f1bd31f762e61237eb23790
> Author: Matthew Wilcox <mawilcox@microsoft.com>
> Date: Thu Jun 7 17:05:13 2018 -0700
>
> slab: __GFP_ZERO is incompatible with a constructor
>
> __GFP_ZERO requests that the object be initialised to all-zeroes, while
> the purpose of a constructor is to initialise an object to a particular
> pattern. We cannot do both. Add a warning to catch any users who
> mistakenly pass a __GFP_ZERO flag when allocating a slab with a
> constructor.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Random warning dump during init.
2018-07-11 18:17 Random warning dump during init Rob Landley
2018-07-12 14:53 ` Rob Landley
2018-07-12 19:59 ` Geert Uytterhoeven
@ 2018-07-12 20:52 ` Matthew Wilcox
2 siblings, 0 replies; 4+ messages in thread
From: Matthew Wilcox @ 2018-07-12 20:52 UTC (permalink / raw)
To: linux-sh
On Thu, Jul 12, 2018 at 09:59:42PM +0200, Geert Uytterhoeven wrote:
> CC willy
>
> On Thu, Jul 12, 2018 at 4:55 PM Rob Landley <rob@landley.net> wrote:
> > On 07/11/2018 01:17 PM, Rob Landley wrote:
> > > Building commit d0fbad0aec1d (from July 2) I hit this, and I confirmed today's
> > > pull is still doing it. (It's my mkroot sh4 target built with musl-cross-make,
> > > booting under qemu.)
> > >
> > > NET: Registered protocol family 17
> > > Freeing unused kernel memory: 116K
> > > This architecture does not have kernel memory protection.
> > > WARNING: CPU: 0 PID: 1 at mm/slub.c:2412 ___slab_alloc.constprop.34+0x196/0x288
> > >
> > > CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0-rc3 #1
> > > PC is at ___slab_alloc.constprop.34+0x196/0x288
> > > PR is at __slab_alloc.constprop.33+0x2a/0x4c
> > > PC : 8c09ada2 SP : 8f829ea8 SR : 400080f0
> > > TEA : c0001240
> > > R0 : 8c09ac0c R1 : 8c01cc54 R2 : 8ff750d0 R3 : 00000000
> > > R4 : 8f802780 R5 : 006080c0 R6 : 8c01d79c R7 : 8ff750d0
> > > R8 : 8c011bd8 R9 : 8ff750d0 R10 : 8f802780 R11 : 00008000
> > > R12 : 8c01d79c R13 : 006080c0 R14 : 8f8027fc
> > > MACH: 00000205 MACL: 0ae4849d GBR : 00000000 PR : 8c09aebe
> > >
> > > Call trace:
> > > [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> > > [<(ptrval)>] __slab_alloc.constprop.33+0x2a/0x4c
> > > [<(ptrval)>] arch_local_save_flags+0x0/0x8
> > > [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> > > [<(ptrval)>] mm_init.isra.6+0xb4/0x104
> > > [<(ptrval)>] kmem_cache_alloc+0x9c/0xf4
> > > [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> > > [<(ptrval)>] mm_init.isra.6+0xb4/0x104
> > > [<(ptrval)>] mm_init.isra.6+0xb4/0x104
> > > [<(ptrval)>] __do_execve_file+0x1da/0x5bc
> > > [<(ptrval)>] kmem_cache_alloc+0x0/0xf4
> > > [<(ptrval)>] getname_kernel+0x1e/0xc8
> > > [<(ptrval)>] do_execve+0x16/0x24
> > > [<(ptrval)>] arch_local_save_flags+0x0/0x8
> > > [<(ptrval)>] arch_local_irq_restore+0x0/0x24
> > > [<(ptrval)>] printk+0x0/0x24
> > > [<(ptrval)>] kernel_init+0x34/0xec
> > > [<(ptrval)>] ret_from_kernel_thread+0xc/0x14
> > > [<(ptrval)>] schedule_tail+0x0/0x54
> > > [<(ptrval)>] kernel_init+0x0/0xec
The stack dump is a bit garbled, but it looks to me like kmem_cache_alloc()
is being called from getname_kernel(). The problem is, neither of the
conditions which must both be satisfied to generate the warning is true.
getname_kernel calls __getname which is:
include/linux/fs.h:#define __getname() kmem_cache_alloc(names_cachep, GFP_KERNEL)
which doesn't have GFP_ZERO set. And names_cachep is created as:
names_cachep = kmem_cache_create_usercopy("names_cache", PATH_MAX, 0,
SLAB_HWCACHE_ALIGN|SLAB_PANIC, 0, PATH_MAX, NULL);
which doesn't have a constructor.
So how you're getting this warning, I have no idea!
> > > ---[ end trace 547fc2facfcadcaf ]---
> > > 8139cp 0000:00:02.0 eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
> > > Type exit when done.
> > > / #
> >
> > I bisected it to:
> >
> > commit 128227e7fe4087b60f1bd31f762e61237eb23790
> > Author: Matthew Wilcox <mawilcox@microsoft.com>
> > Date: Thu Jun 7 17:05:13 2018 -0700
> >
> > slab: __GFP_ZERO is incompatible with a constructor
> >
> > __GFP_ZERO requests that the object be initialised to all-zeroes, while
> > the purpose of a constructor is to initialise an object to a particular
> > pattern. We cannot do both. Add a warning to catch any users who
> > mistakenly pass a __GFP_ZERO flag when allocating a slab with a
> > constructor.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply [flat|nested] 4+ messages in thread