[PATCH] kexec: add resriction on the kexec_load

[zhong jiang]

On 2016/7/20 10:07, 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.
>
> 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.
>
> Eric
  In addition, I had tested when set max segment size to 1G when system memory have 32G,
  the rlock probabilistic come up when trinity run.
>> ck time:20160628120131-243c5
>> rlock reason:SOFT-WATCHDOG detected! on cpu 5.
>> CPU 5 Pid: 9485, comm: trinity-c5
>> RIP: 0010:[<ffffffff8111a4cf>]  [<ffffffff8111a4cf>] next_zones_zonelist+0x3f/0x60
>> RSP: 0018:ffff88088783bc38  EFLAGS: 00000283
>> RAX: ffff8808bffd9b08 RBX: ffff88088783bbb8 RCX: ffff88088783bd30
>> RDX: ffff88088f15a248 RSI: 0000000000000002 RDI: 0000000000000000
>> RBP: ffff88088783bc38 R08: ffff8808bffd8d80 R09: 0000000412c4d000
>> R10: 0000000412c4e000 R11: 0000000000000000 R12: 0000000000000002
>> R13: 0000000000000000 R14: ffff8808bffd9b00 R15: 0000000000000000
>> FS:  00007f91137ee700(0000) GS:ffff88089f2a0000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 000000000016161a CR3: 0000000887820000 CR4: 00000000000407e0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process trinity-c5 (pid: 9485, threadinfo ffff88088783a000, task ffff88088f159980)
>> Stack:
>>  ffff88088783bd88 ffffffff81106eac ffff8808bffd8d80 0000000000000000
>>  0000000000000000 ffffffff8124c2be 0000000000000001 000000000000001e
>>  0000000000000000 ffffffff8124c2be 0000000000000002 ffffffff8124c2be
>> Call Trace:
>>  [<ffffffff81106eac>] __alloc_pages_nodemask+0x14c/0x8f0
>>  [<ffffffff8124c2be>] ? trace_hardirqs_on_thunk+0x3a/0x3c
>>  [<ffffffff8124c2be>] ? trace_hardirqs_on_thunk+0x3a/0x3c
>>  [<ffffffff8124c2be>] ? trace_hardirqs_on_thunk+0x3a/0x3c
>>  [<ffffffff8124c2be>] ? trace_hardirqs_on_thunk+0x3a/0x3c
>>  [<ffffffff8124c2be>] ? trace_hardirqs_on_thunk+0x3a/0x3c
>>  [<ffffffff8113e5ef>] alloc_pages_current+0xaf/0x120
>>  [<ffffffff810a0da0>] kimage_alloc_pages+0x10/0x60
>>  [<ffffffff810a15ad>] kimage_alloc_control_pages+0x5d/0x270
>>  [<ffffffff81027e85>] machine_kexec_prepare+0xe5/0x6c0
>>  [<ffffffff810a0d52>] ? kimage_free_page_list+0x52/0x70
>>  [<ffffffff810a1921>] sys_kexec_load+0x141/0x600
>>  [<ffffffff8115e6b0>] ? vfs_write+0x100/0x180
>>  [<ffffffff8145fbd9>] system_call_fastpath+0x16/0x1b
>>
>> The patch just add condition on sanity_check_segment_list to
>> restriction the segment size.
>>
>> Signed-off-by: zhong jiang <zhongjiang at huawei.com>
>> ---
>>  arch/x86/include/asm/kexec.h |  1 +
>>  kernel/kexec_core.c          | 12 ++++++++++++
>>  2 files changed, 13 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
>> index d2434c1..b31a723 100644
>> --- a/arch/x86/include/asm/kexec.h
>> +++ b/arch/x86/include/asm/kexec.h
>> @@ -67,6 +67,7 @@ struct kimage;
>>  /* Memory to backup during crash kdump */
>>  #define KEXEC_BACKUP_SRC_START	(0UL)
>>  #define KEXEC_BACKUP_SRC_END	(640 * 1024UL)	/* 640K */
>> +#define KEXEC_MAX_SEGMENT_SIZE	(5 * 1024 * 1024UL)	/* 5M */
>>  
>>  /*
>>   * CPU does not save ss and sp on stack if execution is already
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index 448127d..35c5159 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -209,6 +209,18 @@ int sanity_check_segment_list(struct kimage *image)
>>  			return result;
>>  	}
>>  
>> +
>> +	/* Verity all segment size donnot exceed the specified size.
>> + 	 * if segment size from user space is too large,  a large 
>> + 	 * amount of time will be wasted when allocating page. so,
>> + 	 * softlockup may be come up.
>> + 	 */
>> +	for (i = 0; i< nr_segments; i++) {
>> +		if (image->segment[i].memsz > KEXEC_MAX_SEGMENT_SIZE)
>> +			return result;
>> +	}
>> +
>> +
>>  	/*
>>  	 * Verify we have good destination addresses.  Normally
>>  	 * the caller is responsible for making certain we don't
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont at kvack.org"> email at kvack.org </a>
>
> .
>