From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752576AbdJTCiE (ORCPT ); Thu, 19 Oct 2017 22:38:04 -0400 Received: from mail.cn.fujitsu.com ([183.91.158.132]:42164 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751865AbdJTCiB (ORCPT ); Thu, 19 Oct 2017 22:38:01 -0400 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="29399050" Subject: Re: [PATCH 0/4] kaslr: extend movable_node to movable_node=nn[KMG]@ss[KMG] To: Chao Fan , , , , , , , References: <20171019100243.25259-1-fanc.fnst@cn.fujitsu.com> CC: , From: Dou Liyang Message-ID: <900bb043-527b-94ce-da11-7a98f8352150@cn.fujitsu.com> Date: Fri, 20 Oct 2017 10:37:52 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20171019100243.25259-1-fanc.fnst@cn.fujitsu.com> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.167.226.106] X-yoursite-MailScanner-ID: 486CD48029C3.A9765 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: douly.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Chao, Cheer! I have some concerns below. At 10/19/2017 06:02 PM, Chao Fan wrote: > Here is a problem: > Here is a machine with several NUMA nodes and some of them are hot-pluggable. > It's not good for kernel to be extracted in the memory region of movable node. > But in current code, I print the address choosen by kaslr and found it may be > placed in movable node sometimes. To solve this problem, it's better to limit > the memory region choosen by kaslr to immovable node in kaslr.c. But the memory > infomation about if it's hot-pluggable is stored in ACPI SRAT table, which is > parsed after kernel is extracted. So we can't get the detail memory infomation > before extracting kernel. > > So extend the movable_node to movable_node=nn@ss, in which nn means > the size of memory in *immovable* node, and ss means the start position of > this memory region. Then limit kaslr choose memory in these regions. Yes, great. Here we should remember that the situation of 'movable_node=nn@ss' is rare, normal situation is 'movable_node=nn'. So, we should consider our code tendencies for normal situation. ;-) > > There are two policies: > 1. Specify the memory region in *movable* node to avoid: > Then we can use the existing mem_avoid to handle. But if the memory > one movable node was separated by memory hole or different movable nodes > are discontinuous, we don't know how many regions need to avoid. It is not a problem. As you said, we should provide an interface for users later, like that: # cat /sys/device/system/memory/movable_node nn@ss Thanks, dou. > OTOH, we must avoid all of the movable memory, otherwise, kaslr may > choose the wrong place. > 2. Specify the memory region in "immovable* node to select: > Only support 4 regions in this parameter. Then user can use two nodes > at least for kaslr to choose, it's enough for the kernel to extract. > At the same time, because we need only 4 new mem_vector, the usage > of memory here is not too big. > > PATCH 1/4 parse the extended movable_node=nn[KMG]@ss[KMG], then > store the memory regions. > PATCH 2/4 selects the memory region in immovable node when process > memmap. > PATCH 3/4 is the change of document. > PATCH 4/4 cleans up some little problems. > > Chao Fan (4): > kaslr: parse the extended movable_node=nn[KMG]@ss[KMG] > kaslr: select the memory region in immovable node to process > document: change the document for the extended movable_node > kaslr: clean up a useless variable and some usless space > > Documentation/admin-guide/kernel-parameters.txt | 9 ++ > arch/x86/boot/compressed/kaslr.c | 140 +++++++++++++++++++++--- > 2 files changed, 131 insertions(+), 18 deletions(-) >