[PATCH] kexec: add resriction on the kexec_load
zhongjiang at huawei.com
Thu Jul 21 22:52:16 PDT 2016
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
> 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
> 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
> 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
>> 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.
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.
More information about the kexec