From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751394AbdEPCh1 (ORCPT ); Mon, 15 May 2017 22:37:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56308 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751228AbdEPCh0 (ORCPT ); Mon, 15 May 2017 22:37:26 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1421380F6D Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bhe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1421380F6D Date: Tue, 16 May 2017 10:37:19 +0800 From: Baoquan He To: Dou Liyang Cc: tglx@linutronix.de, keescook@chromium.org, mingo@kernel.org, m.mizuma@jp.fujitsu.com, linux-kernel@vger.kernel.org, dyoung@redhat.com, dan.j.williams@intel.com, hpa@zytor.com, x86@kernel.org Subject: Re: [PATCH v5 2/3] KASLR: Handle memory limit specified by memmap and mem option Message-ID: <20170516023719.GB29117@x1> References: <1494654390-23861-1-git-send-email-bhe@redhat.com> <1494654390-23861-3-git-send-email-bhe@redhat.com> <8eea9863-aaec-254b-1ca0-7b12b43a2477@cn.fujitsu.com> <20170516011216.GA29117@x1> <822fdf2e-71a3-5e9e-05b8-78e06c53d777@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <822fdf2e-71a3-5e9e-05b8-78e06c53d777@cn.fujitsu.com> User-Agent: Mutt/1.7.0 (2016-08-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 16 May 2017 02:37:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/16/17 at 09:43am, Dou Liyang wrote: > > > At 05/16/2017 09:12 AM, Baoquan He wrote: > > On 05/16/17 at 08:56am, Dou Liyang wrote: > > > Hi Baoquan, > > > > > > At 05/13/2017 01:46 PM, Baoquan He wrote: > > > > Option mem= will limit the max address a system can use and any memory > > > > region above the limit will be removed. > > > > > > > > Furthermore, memmap=nn[KMG] which has no offset specified has the same > > > > behaviour as mem=. > > > > > > > > KASLR needs to consider this when choosing the random position for > > > > decompressing the kernel. Do it now. > > > > > > > > Signed-off-by: Baoquan He > > > > Tested-by: Masayoshi Mizuma > > > > --- > > > > arch/x86/boot/compressed/kaslr.c | 68 +++++++++++++++++++++++++++++----------- > > > > 1 file changed, 50 insertions(+), 18 deletions(-) > > > > > > > > return -EINVAL; > > > > @@ -173,9 +184,14 @@ static void mem_avoid_memmap(char *str) > > > > if (rc < 0) > > > > break; > > > > str = k; > > > > - /* A usable region that should not be skipped */ > > > > - if (size == 0) > > > > + > > > > + if (start == 0) { > > > > + /* Store the specified memory limit if size > 0 */ > > > > + if (size > 0) > > > > + mem_limit = size; > > > > > > Baoquan, > > > > > > I am not sure about setting the value of mem_limit to mem_size directly. > > > > > > If the command line has both the "memmap" and "mem", such as > > > ... mem=2G memmap=4G ... > > > > > > ...in that code, the mem_limit may be 4G not 2G. > > > > No, could you tell why you want to add both "memmap=nnKMG" and "mem=" at > > the same time? As you sid, what if I add "mem=4G mem=2G mem=1G"? > > Just for testing :) > > Ok, thanks, I see. We should be responsible for our command line. don't > need to consider with these situations in kernel. Thanks for testing and looking into this patchset, Liyang. I understand your worry, this patch is trying to have the same behaviour as in arch/x86/kernel/e820.c. Seems the liability of specifying them right lays on users' shoulder. Thanks Baoquan