linux-kernel - Re: [Bug fix PATCH 1/2] acpi, movablemem_map: Exclude memblock.reserved ranges when parsing SRAT.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Feb 2013 20:35:58 +0800
From:	Will Huck <will.huckk@...il.com>
To:	Tang Chen <tangchen@...fujitsu.com>
CC:	akpm@...ux-foundation.org, jiang.liu@...wei.com,
	wujianguo@...wei.com, hpa@...or.com, wency@...fujitsu.com,
	laijs@...fujitsu.com, linfeng@...fujitsu.com, yinghai@...nel.org,
	isimatu.yasuaki@...fujitsu.com, rob@...dley.net,
	kosaki.motohiro@...fujitsu.com, minchan.kim@...il.com,
	mgorman@...e.de, rientjes@...gle.com, guz.fnst@...fujitsu.com,
	rusty@...tcorp.com.au, lliubbo@...il.com, jaegeuk.hanse@...il.com,
	tony.luck@...el.com, glommer@...allels.com,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [Bug fix PATCH 1/2] acpi, movablemem_map: Exclude memblock.reserved
 ranges when parsing SRAT.

On 02/20/2013 08:31 PM, Tang Chen wrote:
> On 02/20/2013 07:00 PM, Tang Chen wrote:
>> As mentioned by HPA before, when we are using movablemem_map=acpi, if 
>> all the
>> memory ranges in SRAT is hotpluggable, then no memory can be used by 
>> kernel.
>>
>> Before parsing SRAT, memblock has already reserve some memory ranges 
>> for other
>> purposes, such as for kernel image, and so on. We cannot prevent 
>> kernel from
>> using these memory. So we need to exclude these ranges even if these 
>> memory is
>> hotpluggable.
>>
>> This patch changes the movablemem_map=acpi option's behavior. The 
>> memory ranges
>> reserved by memblock will not be added into movablemem_map.map[]. So 
>> even if
>> all the memory is hotpluggable, there will always be memory that 
>> could be used
>> by the kernel.
>>

What's the relationship between e820 map and SRAT?

>> Reported-by: H Peter Anvin<hpa@...or.com>
>> Signed-off-by: Tang Chen<tangchen@...fujitsu.com>
>> ---
>>   arch/x86/mm/srat.c |   18 +++++++++++++++++-
>>   1 files changed, 17 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
>> index 62ba97b..b8028b2 100644
>> --- a/arch/x86/mm/srat.c
>> +++ b/arch/x86/mm/srat.c
>> @@ -145,7 +145,7 @@ static inline int save_add_info(void) {return 0;}
>>   static void __init
>>   handle_movablemem(int node, u64 start, u64 end, u32 hotpluggable)
>>   {
>> -    int overlap;
>> +    int overlap, i;
>>       unsigned long start_pfn, end_pfn;
>>
>>       start_pfn = PFN_DOWN(start);
>> @@ -161,8 +161,24 @@ handle_movablemem(int node, u64 start, u64 end, 
>> u32 hotpluggable)
>>        *
>>        * Using movablemem_map, we can prevent memblock from 
>> allocating memory
>>        * on ZONE_MOVABLE at boot time.
>> +     *
>> +     * Before parsing SRAT, memblock has already reserve some memory 
>> ranges
>> +     * for other purposes, such as for kernel image. We cannot prevent
>> +     * kernel from using these memory, so we need to exclude these 
>> memory
>> +     * even if it is hotpluggable.
>>        */
>>       if (hotpluggable&&  movablemem_map.acpi) {
>> +        /* Exclude ranges reserved by memblock. */
>> +        struct memblock_type *rgn =&memblock.reserved;
>> +
>> +        for (i = 0; i<  rgn->cnt; i++) {
>> +            if (end<= rgn->regions[i].base ||
>> +                start>= rgn->regions[i].base +
>> +                rgn->regions[i].size)
>
> Hi all,
>
> Here, I scan the memblock.reserved each time we parse an entry because 
> the
> rgn->regions[i].nid is set to MAX_NUMNODES in memblock_reserve(). So I 
> cannot
> obtain the nid which the kernel resides in directly from 
> memblock.reserved.
>
> I think there could be some problems if the memory ranges in SRAT are 
> not in
> increasing order, since if [3,4) [1,2) are all on node0, and kernel is 
> not
> using [3,4), but using [1,2), then I cannot remove [3,4) because I 
> don't know
> on which node [3,4) is.
>
> Any idea for this ?
>
> And by the way, I think this approach works well when the memory 
> entries in
> SRAT are arranged in increasing order.
>
> Thanks. :)
>
>> +                continue;
>> +            goto out;
>> +        }
>> +
>>           insert_movablemem_map(start_pfn, end_pfn);
>>
>>           /*
>
> -- 
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/