lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YW/Hb4sVWGOIxzUk@kernel.org>
Date:   Wed, 20 Oct 2021 10:38:23 +0300
From:   Mike Rapoport <rppt@...nel.org>
To:     Qian Cai <quic_qiancai@...cinc.com>
Cc:     Catalin Marinas <catalin.marinas@....com>, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] memblock: exclude NOMAP regions from kmemleak

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:
> > 
> > On 10/19/2021 11:53 AM, Catalin Marinas wrote:
> > > Thanks. I guess the log here is with the Mike's patch reverted.
> > 
> > Yes.
> > 
> > > Try "earlycon=pl011,mmio32,0x12600000" on the kernel command line
> > > and hopefully we get some early log.
> > 
> > Thanks for the suggestion, Catalin. I did not realize that a
> > manually-provided "earlycon" started earlier than just "earlycon"
> > and not defer to ACPI to populate parameters. Anyway,
> > 
> > [	0.000000][	T0] Booting Linux on physical CPU 0x0000000000 [0x503f0002]
> > [	0.000000][	T0] Linux version 5.15.0-rc6-next-20211019+ (root@...in5) (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.

Thoughts?

-- 
Sincerely yours,
Mike.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ