lkml.org 
[lkml]   [2021]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] memblock: exclude NOMAP regions from kmemleak
On Wed, Oct 20, 2021 at 11:42:28AM +0300, Mike Rapoport wrote:
> On Wed, Oct 20, 2021 at 09:18:46AM +0100, Catalin Marinas wrote:
> > On Wed, Oct 20, 2021 at 10:38:23AM +0300, Mike Rapoport wrote:
> > > On Tue, Oct 19, 2021 at 09:33:11PM +0300, Mike Rapoport wrote:
> > > > On Tue, Oct 19, 2021 at 01:59:22PM -0400, Qian Cai wrote:
> > > > > [ 0.000000][ T0] Booting Linux on physical CPU 0x0000000000 [0x503f0002]
> > > > > [ 0.000000][ T0] Linux version 5.15.0-rc6-next-20211019+ (root@admin5) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #104 SMP Tue Oct 19 17:36:17 UTC 2021
> > > > > [ 0.000000][ T0] earlycon: pl11 at MMIO32 0x0000000012600000 (options '')
> > > > > [ 0.000000][ T0] printk: bootconsole [pl11] enabled
> > > > > [ 0.000000][ T0] efi: Getting UEFI parameters from /chosen in DT:
> > > > > [ 0.000000][ T0] efi: System Table : 0x0000009ff7de0018
> > > > > [ 0.000000][ T0] efi: MemMap Address : 0x0000009fe6dae018
> > > > > [ 0.000000][ T0] efi: MemMap Size : 0x0000000000000600
> > > > > [ 0.000000][ T0] efi: MemMap Desc. Size : 0x0000000000000030
> > > > > [ 0.000000][ T0] efi: MemMap Desc. Version : 0x0000000000000001
> > > > > [ 0.000000][ T0] efi: EFI v2.70 by American Megatrends
> > > > > [ 0.000000][ T0] efi: ACPI 2.0=0x9ff5b40000 SMBIOS 3.0=0x9ff686fd98 ESRT=0x9ff1d18298 MEMRESERVE=0x9fe6dacd98
> > > > > [ 0.000000][ T0] efi: Processing EFI memory map:
> > > > > [ 0.000000][ T0] efi: 0x000090000000-0x000091ffffff [Conventional| | | | | | | | | | |WB|WT|WC|UC]
> > > > > [ 0.000000][ T0] efi: 0x000092000000-0x0000928fffff [Runtime Data|RUN| | | | | | | | | |WB|WT|WC|UC]
> > > > > [ 0.000000][ T0] ------------[ cut here ]------------
> > > > > [ 0.000000][ T0] kernel BUG at mm/kmemleak.c:1140!
> > > > > [ 0.000000][ T0] Internal error: Oops - BUG: 0 [#1] SMP
> > > > >
> > > > > I did not quite figure out where this BUG() was triggered and I did not
> > > >
> > > > This is from here:
> > > > arch/arm64/include/asm/memory.h:
> > > >
> > > > #define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
> > > >
> > > > kmemleak_free_part_phys() does __va() which uses PHYS_OFFSET and all this
> > > > happens before memstart_addr is set.
> > > >
> > > > I'll try to see how this can be untangled...
> > >
> > > This late in the cycle I can only think of reverting kmemleak wavier from
> > > memblock_mark_nomap() and putting it in
> > > early_init_dt_alloc_reserved_memory_arch() being the only user setting
> > > MEMBLOCK_NOMAP to an allocated chunk rather than marking NOMAP "unusable"
> > > memory reported by firmware.
> >
> > It makes sense, there aren't many places or nomap is called.
> >
> > I think arch_reserve_mem_area() called from acpi_table_upgrade() also
> > follows a memblock allocation. But I'd call kmemleak in
> > acpi_table_upgrade() directly rather than in the arch back-end.
>
> Hmm, not sure this is correct for x86. I don't see why can't it track the
> memory allocated in acpi_table_upgrade().

Kmemleak still tracks it after an ignore but it won't be scanned. I
don't think this memory contains pointers to virtual addresses.

--
Catalin

\
 
 \ /
  Last update: 2021-10-20 11:34    [W:0.043 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site