[PATCH] kexec: add resriction on the kexec_load

[Dave Young]

On 07/19/16 at 09:07pm, Eric W. Biederman wrote:
> zhongjiang <zhongjiang at huawei.com> writes:
> 
> > From: zhong jiang <zhongjiang at huawei.com>
> >
> > I hit the following question when run trinity in my system. The
> > kernel is 3.4 version. but the mainline have same question to be
> > solved. The root cause is the segment size is too large, it can
> > expand the most of the area or the whole memory, therefore, it
> > may waste an amount of time to abtain a useable page. and other
> > cases will block until the test case quit. at the some time,
> > OOM will come up.
> 
> 5MiB is way too small.  I have seen vmlinux images not to mention
> ramdisks that get larger than that.  Depending on the system
> 1GiB might not be an unreasonable ramdisk size.  AKA run an entire live
> system out of a ramfs.  It works well if you have enough memory.

There was a use case from Michael Holzheu about a 1.5G ramdisk, see below
kexec-tools commit:

commit 95741713e790fa6bde7780bbfb772ad88e81a744
Author: Michael Holzheu <holzheu at linux.vnet.ibm.com>
Date:   Fri Oct 30 16:02:04 2015 +0100

    kexec/s390x: use mmap instead of read for slurp_file()
    
    The slurp_fd() function allocates memory and uses the read() system
call.
    This results in double memory consumption for image and initrd:
    
     1) Memory allocated in user space by the kexec tool
     2) Memory allocated in kernel by the kexec() system call
    
    The following illustrates the use case that we have on s390x:
    
     1) Boot a 4 GB Linux system
     2) Copy kernel and 1,5 GB ramdisk from external source into tmpfs
(ram)
     3) Use kexec to boot kernel with ramdisk
    
     Therefore for kexec runtime we need:
    
     1,5 GB (tmpfs) + 1,5 GB (kexec malloc) + 1,5 GB (kernel memory) =
4,5 GB
    
    This patch introduces slurp_file_mmap() which for "normal" files
uses
    mmap() instead of malloc()/read(). This reduces the runtime memory
    consumption of the kexec tool as follows:
    
     1,5 GB (tmpfs) + 1,5 GB (kernel memory) = 3 GB
    
    Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com>
    Reviewed-by: Dave Young <dyoung at redhat.com>
    Signed-off-by: Simon Horman <horms at verge.net.au>

> 
> I think there is a practical limit at about 50% of memory (because we
> need two copies in memory the source and the destination pages), but
> anything else is pretty much reasonable and should have a fair chance of
> working.
> 
> A limit that reflected that reality above would be interesting.
> Anything else will likely cause someone trouble in the futrue.

Maybe one should test his ramdisk first to ensure it works first before
really using it.

Thanks
Dave