linux-kernel - alloc_bootmem

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 13 Mar 2009 14:53:02 +0000
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	<hannes@...xchg.org>, "Ingo Molnar" <mingo@...e.hu>
Cc:	<linux-kernel@...r.kernel.org>
Subject: alloc_bootmem_low() mis-uses

As you are being listed as the authors of mm/bootmem.c, I'd like to raise
the following issues in the hope that you can shed some additional light on
the original intentions of that code.

>From looking at all the callers of this and similar functions I'm getting the
impression that the majority of them are actually mis-uses: These functions
should really only be used when there is a need for getting an address
below ARCH_LOW_ADDRESS_LIMIT, but they should in particular not be
used just because the caller wants to make sure he doesn't get any
highmem range back (which is because highmem never enters the bootmem
allocator in the first place). Or am I missing something here?

A second aspect is that there is no attempt to preserve memory below
ARCH_LOW_ADDRESS_LIMIT for those few callers that really need to
get such memory (swiotlb, ACPI sleep) - 'normal' bootmem allocations
honor MAX_DMA_ADDRESS, but not ARCH_LOW_ADDRESS_LIMIT. This
apparently can, on systems with very much memory, lead to earlier
huge allocations (e.g. alloc_large_system_hash() and
alloc_node_mem_map()) exhausting almost all of the memory below that
boundary. Not avoiding that area may also result in unnecessary
pressure on later GFP_DMA32 allocations.

Wouldn't it therefore be reasonable to
- eliminate all the bogus callers of alloc_bootmem_low() & Co,
- change ___alloc_bootmem_nopanic() to use a three (or even multi) stage
  search, based on the fact that the goal argument isn't something that
  must be strictly adhered to anyway, and
- change alloc_bootmem_core() to start allocating from the top rather
  than the bottom?

Thanks, Jan

--
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/