Hi Maxim,
Could you please send us your .config file as well?
Maxim Levitsky <maximlevitsky@gmail.com> wrote:
It may crash before you get to this point. Anyway, there is no scanning
taking place during booting - there is a specific 1 minute delay to
avoid slowing down the boot process.
I don't think the problem is caused by kmemleak (see below).
Kmemleak shouldn't cause a panic, it just prints the message and
disables itself.
This kmemleak warning tells us that the kmemleak_alloc() hook got called
with a pointer (0xffff880079fe6000) that's already registered with
kmemleak. The first trace tells us where the hook gets called from while
the second trace shows the details of the already existing pointer.
So __getname() allocates the same 4096 bytes block twice via
kmem_cache_alloc() but there is no kmemleak_free() call between them and
kmemleak gives up. It disables itself but does not panic the system.
Pekka, were there any recent changes in the slab/slob/slub area and
maybe a kmemleak_free() hook is missing? Or maybe something else went
wrong with the slab allocator and returns an already allocated block?
That's what's causing the fault but it doesn't seem to be related to
kmemleak.
Thanks.
--
Catalin
--