Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 14 Feb 2019 12:39:46 -0500
From:   Masayoshi Mizuma <msys.mizuma@gmail.com>
To:     Baoquan He <bhe@redhat.com>
Cc:     Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "kirill@shutemov.name Thomas Gleixner" <tglx@linutronix.de>,
        x86@kernel.org, Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>,
        linux-kernel@vger.kernel.org, Chao Fan <fanc.fnst@cn.fujitsu.com>
Subject: Re: [PATCH v2] x86/mm: Adjust the padding size for KASLR
Message-ID: <20190214173945.utbawbfbdjkw7dif@gabell>
References: <20190212013118.28203-1-msys.mizuma@gmail.com>
 <20190214101236.GE14858@MiWiFi-R3L-srv>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190214101236.GE14858@MiWiFi-R3L-srv>
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Baoquan,

Thank you for your review.

On Thu, Feb 14, 2019 at 06:12:36PM +0800, Baoquan He wrote:
> Hi Masa,
> 
> On 02/11/19 at 08:31pm, Masayoshi Mizuma wrote:
> > From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> > 
> > The system sometimes crashes while memory hot-adding on KASLR
> > enabled system. The crash happens because the regions pointed by
> > kaslr_regions[].base are overwritten by the hot-added memory.
> > 
> > It happens because of the padding size for kaslr_regions[].base isn't
> > enough for the system whose physical memory layout has huge space for
> > memory hotplug. kaslr_regions[].base points "actual installed
> > memory size + padding" or higher address. So, if the "actual + padding"
> > is lower address than the maximum memory address, which means the memory
> > address reachable by memory hot-add, kaslr_regions[].base is destroyed by
> > the overwritten.
> > 
> >   address
> >     ^
> >     |------- maximum memory address (Hotplug)
> >     |                                    ^
> >     |------- kaslr_regions[0].base       | Hotadd-able region
> >     |     ^                              |
> >     |     | padding                      |
> >     |     V                              V
> >     |------- actual memory address (Installed on boot)
> >     |
> > 
> > Fix it by getting the maximum memory address from SRAT and store
> > the value in boot_param, then set the padding size while kaslr
> > initializing if the default padding size isn't enough.
> 
> Thanks for the effort on fixing this KASLR&hotplug conflict issue.
> I roughly go through this patch, seems three parts are contained:
>  
> 1) Wrap up the SRAT travesing code into subtable_parse();
> 2) Add a field max_addr in struct boot_params, and get the max address
>    from SRAT and write it into boot_params->max_addr;
> 3) Add kaslr_padding() to adjust the padding size for the direct
> mapping. 
> 
> So could you split them into three patches for better reviewing?

Yes, I will split into the three.

> 
> Another thing is for the 3rd part, I also queued several patches in my
> local branch, they are code bug fix patches, and several clean up
> patches suggested by Ingo and Kirill. They can be found here:
> 
> https://github.com/baoquan-he/linux/commits/kaslar-mm-bug-fix
> 
> In my local patches, Ingo suggested opening code get_padding(), and
> about the SGI UV bug, he suggested adding another function to calculate
> the needed size for the direct mapping region. So I am wondering if you
> can rebase the part 3 on top of it, or you add a new function to
> calculate the size for the direct mapping region so that I can rebase on
> top of your patch and reuse it.
> 
> What do you think about it?

OK, I will rebase my patches on top of your patch.
Could you add CCing me when you post your patches?

Thanks!
Masa