lkml.org 
[lkml]   [2013]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v3 08/21] vmcore: copy non page-size aligned head and tail pages in 2nd kernel
HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> writes:

> Due to mmap() requirement, we need to copy pages not starting or
> ending with page-size aligned address in 2nd kernel and to map them to
> user-space.
>
> For example, see the map below:
>
> 00000000-00010000 : reserved
> 00010000-0009f800 : System RAM
> 0009f800-000a0000 : reserved
>
> where the System RAM ends with 0x9f800 that is not page-size
> aligned. This map is divided into two parts:
>
> 00010000-0009f000
> 0009f000-0009f800
>
> and the first one is kept in old memory and the 2nd one is copied into
> buffer on 2nd kernel.
>
> This kind of non-page-size-aligned area can always occur since any
> part of System RAM can be converted into reserved area at runtime.
>
> If not doing copying like this and if remapping non page-size aligned
> pages on old memory directly, mmap() had to export memory which is not
> dump target to user-space. In the above example this is reserved
> 0x9f800-0xa0000.

So I have a question. Would it not be easier to only support mmaping on
the things that are easily mmapable? And in the oddball corner cases
require reading the data instead.

My gut feel says that would reduce the net complexity of the system a
bit, and would also reduce the amount of memory that the kernel has to
allocate.

Alrernatively and probably better given the nature of what is happening
here. It seems entirely reasonable to round up the boundaries of the
supported mappings to the nearest page. A little memory leak of data
in a reserved page should be harmless.

Eric


\
 
 \ /
  Last update: 2013-03-19 22:41    [W:0.667 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site