From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932632AbdEUXOn (ORCPT ); Sun, 21 May 2017 19:14:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54444 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932369AbdEUXOm (ORCPT ); Sun, 21 May 2017 19:14:42 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BC9443680C Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=bhe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BC9443680C Date: Mon, 22 May 2017 07:14:37 +0800 From: Baoquan He To: Thomas Garnier Cc: LKML , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers , Kees Cook , Andrew Morton , Masahiro Yamada Subject: Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system Message-ID: <20170521231437.GA3798@x1> References: <1495281758-11320-1-git-send-email-bhe@redhat.com> <1495281758-11320-3-git-send-email-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.30]); Sun, 21 May 2017 23:14:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/21/17 at 01:38pm, Thomas Garnier wrote: > On Sat, May 20, 2017 at 5:02 AM, Baoquan He wrote: > > arch/x86/mm/kaslr.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c > > index aed2064..20b0456 100644 > > --- a/arch/x86/mm/kaslr.c > > +++ b/arch/x86/mm/kaslr.c > > @@ -27,6 +27,7 @@ > > #include > > #include > > #include > > +#include > > > > #include "mm_internal.h" > > > > @@ -123,7 +124,7 @@ void __init kernel_randomize_memory(void) > > CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING; > > > > /* Adapt phyiscal memory region size based on available memory */ > > - if (memory_tb < kaslr_regions[0].size_tb) > > + if (memory_tb < kaslr_regions[0].size_tb && !is_early_uv_system()) > > Given your example, any way we could just restrict memory_tb to be > 32TB? Or different configurations will result in different mappings? Thanks for looking into this, Thomas! For that machine where I used to reproduce the bug and test, 32TB memory need be mapped to the direct mapping region. I am not sure if SGI UV system has larger MMIOH region now or in the future in different machine. If they have machine owning MMIOH region bigger than 64TB, then it's a problem SGI UV need fix because that will break system whether kaslr enabled or not. Hi Mike, Russ and Frank, About Thomas's question, could you help answer it? Could other SGI UV system has MMIOH region bigger than 32TB? Thanks Baoquan > > > kaslr_regions[0].size_tb = memory_tb; > > > > /* Calculate entropy available between regions */