[PATCH] kexec: add resriction on the kexec_load

[zhong jiang]

On 2016/7/21 16:10, Dave Young wrote:
> 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
>
> .
>
 Thank you reply.  I just test the syscall kexec_load, I don't really run kexec iamge to boot machine.
 Recently , I hit the question. I fix it by passing resonable parameters to kernel from user space.
 no functional change.   is right?  
 according to the W. Biederman advice, I agree so.