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>] [day] [month] [year] [list]
Date:	Tue, 04 Sep 2007 08:48:35 -0400
From:	Chris Snook <csnook@...hat.com>
To:	James Georgas <jgeorgas@...ers.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: HIMEM calculation

James Georgas wrote:
>  > That's the vmalloc address space.  You only get 896 MB in the NORMAL
>  > zone on i386, to leave room for vmalloc.  If you don't like it, go 
> 64-bit.
>  >
>  >       -- Chris
> 
> I like it fine. I just didn't understand it. Thanks for answering.
> 
> So, basically, the vmalloc address space is not backed by physical RAM,
> right? Rather, the virtual address space associated with vmalloc is
> mapped to physical pages by page tables?

Basically, yes, but that's an oversimplification.  We actually use page tables 
everywhere, but the conversion is simply +/- 0xC0000000 for the NORMAL zone, so 
we can skip most of the fancy VM work and just use a trivial macro.  vmalloc can 
allocate large chunks of virtually contiguous memory even when the physical 
memory is heavily fragmented, and since we've set aside address space for it, 
it's visible in all process contexts.

vmalloc is handy sometimes because it can complete even if there's no memory 
free when it's called, since the VM will swap out user pages and then return 
those remapped into the vmalloc address space.  Unfortunately, we can't use 
vmalloc anywhere we want to use DMA because it will be accessed without the MMU. 
  Worse, we also can't use it in any path that could be called while trying to 
free memory, due to recursion issues, which substantially limits its utility in 
the kernel.  Some people *cough*OpenAFS*cough* use it carelessly and get all 
kinds of exciting panics under rare and difficult-to-reproduce load conditions.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ