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.miz...@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
