linux-kernel - Re: kmemleak, cpu usage jump out of nowhere

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: <C36A97B2-E6A4-409D-91B8-DED8B086A479@gmail.com>
Date:	Fri, 16 Jul 2010 22:29:59 +0200
From:	Zeno Davatz <zdavatz@...il.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Damien Wyart <damien.wyart@...e.fr>,
	Catalin Marinas <catalin.marinas@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"x86@...nel.org" <x86@...nel.org>, "mingo@...e.hu" <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: kmemleak, cpu usage jump out of nowhere


Am 16.07.2010 um 20:27 schrieb Yinghai Lu <yinghai@...nel.org>:

> it seems that you are using 32bit kernel. please check if this one help.

Thanks! What RC should I patch? 2.6.35-rc5?

Best
Zeno

> Subject: [PATCH -v3] x86,mm: fix 32bit numa sparsemem
> 
> Borislav Petkov <borislav.petkov@....com> reported his 32bit numa has problem:
> 
> [    0.000000] Reserving total of 4c00 pages for numa KVA remap
> [    0.000000] kva_start_pfn ~ 32800 max_low_pfn ~ 375fe
> [    0.000000] max_pfn = 238000
> [    0.000000] 8202MB HIGHMEM available.
> [    0.000000] 885MB LOWMEM available.
> [    0.000000]   mapped low ram: 0 - 375fe000
> [    0.000000]   low ram: 0 - 375fe000
> [    0.000000] alloc (nid=8 100000 - 7ee00000) (1000000 - ffffffff) 1000 1000 => 34e7000
> [    0.000000] alloc (nid=8 100000 - 7ee00000) (1000000 - ffffffff) 200 40 => 34c9d80
> [    0.000000] alloc (nid=0 100000 - 7ee00000) (1000000 - ffffffffffffffff) 180 40 => 34e6140
> [    0.000000] alloc (nid=1 80000000 - c7e60000) (1000000 - ffffffffffffffff) 240 40 => 80000000
> [    0.000000] BUG: unable to handle kernel paging request at 40000000
> [    0.000000] IP: [<c2c8cff1>] __alloc_memory_core_early+0x147/0x1d6
> [    0.000000] *pdpt = 0000000000000000 *pde = f000ff53f000ff00 
> ...
> [    0.000000] Call Trace:
> [    0.000000]  [<c2c8b4f8>] ? __alloc_bootmem_node+0x216/0x22f
> [    0.000000]  [<c2c90c9b>] ? sparse_early_usemaps_alloc_node+0x5a/0x10b
> [    0.000000]  [<c2c9149e>] ? sparse_init+0x1dc/0x499
> [    0.000000]  [<c2c79118>] ? paging_init+0x168/0x1df
> [    0.000000]  [<c2c780ff>] ? native_pagetable_setup_start+0xef/0x1bb
> 
> looks like it allocate much high address for bootmem.
> 
> try to cut limit with get_max_mapped()
> 
> -v3: make alloc_bootmem_node could fallback to other node.
>     just like old alloc_bootmem_node did
> 
> need this patch for 2.6.34 and 2.6.35
> 
> Reported-by: Borislav Petkov <borislav.petkov@....com>
> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
> Cc: stable@...nel.org
> 
> ---
> mm/bootmem.c    |   24 ++++++++++++++++++++----
> mm/page_alloc.c |    3 +++
> 2 files changed, 23 insertions(+), 4 deletions(-)
> 
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -3634,6 +3634,9 @@ void * __init __alloc_memory_core_early(
>    int i;
>    void *ptr;
> 
> +    if (limit > get_max_mapped())
> +        limit = get_max_mapped();
> +
>    /* need to go over early_node_map to find out good range for node */
>    for_each_active_range_index_in_nid(i, nid) {
>        u64 addr;
> Index: linux-2.6/mm/bootmem.c
> ===================================================================
> --- linux-2.6.orig/mm/bootmem.c
> +++ linux-2.6/mm/bootmem.c
> @@ -833,15 +833,24 @@ static void * __init ___alloc_bootmem_no
> void * __init __alloc_bootmem_node(pg_data_t *pgdat, unsigned long size,
>                   unsigned long align, unsigned long goal)
> {
> +    void *ptr;
> +
>    if (WARN_ON_ONCE(slab_is_available()))
>        return kzalloc_node(size, GFP_NOWAIT, pgdat->node_id);
> 
> #ifdef CONFIG_NO_BOOTMEM
> -    return __alloc_memory_core_early(pgdat->node_id, size, align,
> +    ptr = __alloc_memory_core_early(pgdat->node_id, size, align,
> +                     goal, -1ULL);
> +    if (ptr)
> +        return ptr;
> +
> +    ptr = __alloc_memory_core_early(MAX_NUMNODES, size, align,
>                     goal, -1ULL);
> #else
> -    return ___alloc_bootmem_node(pgdat->bdata, size, align, goal, 0);
> +    ptr = ___alloc_bootmem_node(pgdat->bdata, size, align, goal, 0);
> #endif
> +
> +    return ptr;
> }
> 
> void * __init __alloc_bootmem_node_high(pg_data_t *pgdat, unsigned long size,
> @@ -977,14 +986,21 @@ void * __init __alloc_bootmem_low(unsign
> void * __init __alloc_bootmem_low_node(pg_data_t *pgdat, unsigned long size,
>                       unsigned long align, unsigned long goal)
> {
> +    void *ptr;
> +
>    if (WARN_ON_ONCE(slab_is_available()))
>        return kzalloc_node(size, GFP_NOWAIT, pgdat->node_id);
> 
> #ifdef CONFIG_NO_BOOTMEM
> -    return __alloc_memory_core_early(pgdat->node_id, size, align,
> +    ptr = __alloc_memory_core_early(pgdat->node_id, size, align,
> +                goal, ARCH_LOW_ADDRESS_LIMIT);
> +    if (ptr)
> +        return ptr;
> +    ptr = __alloc_memory_core_early(MAX_NUMNODES, size, align,
>                goal, ARCH_LOW_ADDRESS_LIMIT);
> #else
> -    return ___alloc_bootmem_node(pgdat->bdata, size, align,
> +    ptr = ___alloc_bootmem_node(pgdat->bdata, size, align,
>                goal, ARCH_LOW_ADDRESS_LIMIT);
> #endif
> +    return ptr;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/