Re: Several suspected memory leaks
Catalin Marinas writes: > On Wed, 11 Jul 2018 at 00:40, Benjamin Herrenschmidt > wrote: >> On Tue, 2018-07-10 at 17:17 +0200, Paul Menzel wrote: >> > On a the IBM S822LC (8335-GTA) with Ubuntu 18.04 I built Linux master >> > – 4.18-rc4+, commit 092150a2 (Merge branch 'for-linus' >> > of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid) – with >> > kmemleak. Several issues are found. >> >> Some of these are completely uninteresting though and look like >> kmemleak bugs to me :-) >> >> > [] __pud_alloc+0x80/0x270 >> > [<07135d64>] hash__map_kernel_page+0x30c/0x4d0 >> > [<71677858>] __ioremap_at+0x108/0x140 >> > [<0023e921>] __ioremap_caller+0x130/0x180 >> > [<9dbc3923>] icp_native_init_one_node+0x5cc/0x760 >> > [<15f3168a>] icp_native_init+0x70/0x13c >> > [<60ed>] xics_init+0x38/0x1ac >> > [<88dbf9d1>] pnv_init_IRQ+0x30/0x5c >> >> This is the interrupt controller mapping its registers, why on earth >> would that be considered a leak ? kmemleak needs to learn to ignore >> kernel page tables allocations. > > Indeed, that's just a false positive for powerpc. Kmemleak ignores > page allocations and most architectures use __get_free_pages() for the > page table. In this particular case, the powerpc code uses > kmem_cache_alloc() and that's tracked by kmemleak. Since the pgd > stores the __pa(pud), kmemleak doesn't detect this pointer and reports > it as a leak. To work around this, you can pass SLAB_NOLEAKTRACE to > kmem_cache_create() in pgtable_cache_add() Ah thanks, I didn't know we could do it that way. I did this instead which seems to work: https://git.kernel.org/torvalds/c/a984506c542e cheers
Re: Several suspected memory leaks
(catching up with emails) On Wed, 11 Jul 2018 at 00:40, Benjamin Herrenschmidt wrote: > On Tue, 2018-07-10 at 17:17 +0200, Paul Menzel wrote: > > On a the IBM S822LC (8335-GTA) with Ubuntu 18.04 I built Linux master > > – 4.18-rc4+, commit 092150a2 (Merge branch 'for-linus' > > of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid) – with > > kmemleak. Several issues are found. > > Some of these are completely uninteresting though and look like > kmemleak bugs to me :-) > > > [] __pud_alloc+0x80/0x270 > > [<07135d64>] hash__map_kernel_page+0x30c/0x4d0 > > [<71677858>] __ioremap_at+0x108/0x140 > > [<0023e921>] __ioremap_caller+0x130/0x180 > > [<9dbc3923>] icp_native_init_one_node+0x5cc/0x760 > > [<15f3168a>] icp_native_init+0x70/0x13c > > [<60ed>] xics_init+0x38/0x1ac > > [<88dbf9d1>] pnv_init_IRQ+0x30/0x5c > > This is the interrupt controller mapping its registers, why on earth > would that be considered a leak ? kmemleak needs to learn to ignore > kernel page tables allocations. Indeed, that's just a false positive for powerpc. Kmemleak ignores page allocations and most architectures use __get_free_pages() for the page table. In this particular case, the powerpc code uses kmem_cache_alloc() and that's tracked by kmemleak. Since the pgd stores the __pa(pud), kmemleak doesn't detect this pointer and reports it as a leak. To work around this, you can pass SLAB_NOLEAKTRACE to kmem_cache_create() in pgtable_cache_add() (arch/powerpc/mm/init-common.c). -- Catalin
Re: Several suspected memory leaks
Michael Ellerman writes: > Hi Paul, > > Paul Menzel writes: >> Dear Liunx folks, >> >> On a the IBM S822LC (8335-GTA) with Ubuntu 18.04 I built Linux master >> – 4.18-rc4+, commit 092150a2 (Merge branch 'for-linus' >> of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid) – with >> kmemleak. Several issues are found. > > Is this the first time you've tested it? > Or did these warnings only show up recently? > >> ``` >> $ grep KMEMLEAK /boot/config-4.18.0-rc4+ >> CONFIG_HAVE_DEBUG_KMEMLEAK=y >> CONFIG_DEBUG_KMEMLEAK=y >> CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=1 >> # CONFIG_DEBUG_KMEMLEAK_TEST is not set >> # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set > > > I'm not seeing any warnings on my machine here, maybe it's something > config related. Can you send your full .config ? Scratch that. I just didn't wait long enough. cheers
Re: Several suspected memory leaks
Hi Paul, Paul Menzel writes: > Dear Liunx folks, > > On a the IBM S822LC (8335-GTA) with Ubuntu 18.04 I built Linux master > – 4.18-rc4+, commit 092150a2 (Merge branch 'for-linus' > of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid) – with > kmemleak. Several issues are found. Is this the first time you've tested it? Or did these warnings only show up recently? > ``` > $ grep KMEMLEAK /boot/config-4.18.0-rc4+ > CONFIG_HAVE_DEBUG_KMEMLEAK=y > CONFIG_DEBUG_KMEMLEAK=y > CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=1 > # CONFIG_DEBUG_KMEMLEAK_TEST is not set > # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set I'm not seeing any warnings on my machine here, maybe it's something config related. Can you send your full .config ? cheers
Re: Several suspected memory leaks
On Tue, 2018-07-10 at 17:17 +0200, Paul Menzel wrote: > Dear Liunx folks, > > > On a the IBM S822LC (8335-GTA) with Ubuntu 18.04 I built Linux master > – 4.18-rc4+, commit 092150a2 (Merge branch 'for-linus' > of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid) – with > kmemleak. Several issues are found. Some of these are completely uninteresting though and look like kmemleak bugs to me :-) > [] __pud_alloc+0x80/0x270 > [<07135d64>] hash__map_kernel_page+0x30c/0x4d0 > [<71677858>] __ioremap_at+0x108/0x140 > [<0023e921>] __ioremap_caller+0x130/0x180 > [<9dbc3923>] icp_native_init_one_node+0x5cc/0x760 > [<15f3168a>] icp_native_init+0x70/0x13c > [<60ed>] xics_init+0x38/0x1ac > [<88dbf9d1>] pnv_init_IRQ+0x30/0x5c This is the interrupt controller mapping its registers, why on earth would that be considered a leak ? kmemleak needs to learn to ignore kernel page tables allocations. > [ ] __pud_alloc+0x80/0x270 > [<2cdcd2db>] vmap_page_range_noflush+0x670/0x880 > [<41cc3e80>] map_vm_area+0x58/0xb0 > [ ] __vmalloc_node_range+0x1cc/0x3f0 > [ ] __vmalloc+0x50/0x60 > [<27a0846e>] alloc_large_system_hash+0x3b8/0x554 > [ ] vfs_caches_init+0xd4/0x138 > [<55b60f04>] start_kernel+0x60c/0x684 > [ ] start_here_common+0x1c/0x520 This looks like some generic VFS stuff which similarly is meant to remain for the whole duration of the system, what's the point on reporting on init leaks like that ? > unreferenced object 0xc7bd8000 (size 16384): > comm "init", pid 1, jiffies 4294895064 (age 1316.236s) > hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > backtrace: > [ ] __pud_alloc+0x80/0x270 > [<6ee9b8a3>] move_page_tables+0xd6c/0x13d0 > [<91930c94>] shift_arg_pages+0xc8/0x220 > [<9cfa5804>] setup_arg_pages+0x26c/0x380 > [ ] load_elf_binary+0x600/0x29ac > [<5bbeae4b>] search_binary_handler+0x114/0x330 > [ ] __do_execve_file.isra.8+0x8a4/0x10b0 > [<44d8a16f>] sys_execve+0x58/0x70 > [<1deb923d>] system_call+0x5c/0x70 This is odd, looks like a page table allocation, I'm pretty sure those get freed when the corresponding process dies, but this is init (PID1), it probably never does. Again, a false positive. > unreferenced object 0xc7bc8000 (size 16384): > comm "init", pid 1, jiffies 4294895064 (age 1316.236s) > hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > backtrace: > [ ] __pud_alloc+0x80/0x270 > [<1cb1e8bb>] __handle_mm_fault+0x34c/0x2f20 > [<28b41470>] handle_mm_fault+0x1f0/0x4e0 > [ ] __do_page_fault+0x274/0xf90 > [<94f967e0>] handle_page_fault+0x18/0x38 > [ ] 0xc07fce3bbaf0 > [ ] load_elf_binary+0x99c/0x29ac > [<5bbeae4b>] search_binary_handler+0x114/0x330 > [ ] __do_execve_file.isra.8+0x8a4/0x10b0 > [<44d8a16f>] sys_execve+0x58/0x70 > [<1deb923d>] system_call+0x5c/0x70 > unreferenced object 0xc07fb84d (size 16384): > comm "systemd-journal", pid 1796, jiffies 4294895847 (age 1313.168s) > hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > backtrace: > [ ] __pud_alloc+0x80/0x270 > [<6ee9b8a3>] move_page_tables+0xd6c/0x13d0 > [<91930c94>] shift_arg_pages+0xc8/0x220 > [<9cfa5804>] setup_arg_pages+0x26c/0x380 > [ ] load_elf_binary+0x600/0x29ac > [<5bbeae4b>] search_binary_handler+0x114/0x330 > [ ] __do_execve_file.isra.8+0x8a4/0x10b0 > [<44d8a16f>] sys_execve+0x58/0x70 > [<1deb923d>] system_call+0x5c/0x70 > unreferenced object 0xc07fb84b (size 16384): > comm "systemd-journal", pid 1796, jiffies 4294895847 (age 1313.168s) > hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > backtrace: > [ ] __pud_alloc+0x80/0x270 > [<1cb1e8bb>] __handle_mm_fault+0x34c/0x2f20 > [<28b41470>] handle_mm_fault+0x1f0/0x4e0 > [ ] __do_page_fault+0x274/0xf90 > [<94f967e0>] handle_page_fault+0x18/0x38 >
