linux-kernel - Re: [RFC PATCH 3/3] mm,memory_hotplug: Allocate memmap from the added memory range

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:   Fri, 20 Nov 2020 10:31:05 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Oscar Salvador <osalvador@...e.de>
Cc:     mhocko@...nel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, vbabka@...e.cz, pasha.tatashin@...een.com
Subject: Re: [RFC PATCH 3/3] mm,memory_hotplug: Allocate memmap from the added
 memory range


>>> -	move_pfn_range_to_zone(zone, pfn, nr_pages, NULL, MIGRATE_ISOLATE);
>>> +	move_pfn_range_to_zone(zone, pfn, nr_pages, nr_vmemmap_pages, NULL,
>>> +			       MIGRATE_ISOLATE);
>>
>> As mentioned, I'd suggest properly initializing the memmap here
>>
>> if (nr_vmemmap_pages) {
>> 	move_pfn_range_to_zone(zone, pfn, nr_vmemmap_pages, NULL,
>> 			       MIGRATE_UNMOVABLE);
>> }
>> move_pfn_range_to_zone(zone, valid_start_pfn, valid_nr_pages, NULL,
> 
> Sure, agreed.
> 
>>> +	if (!support_memmap_on_memory(size))
>>> +		mhp_flags &= ~MEMHP_MEMMAP_ON_MEMORY;
>>
>> Callers (e.g., virtio-mem) might rely on this. We should reject this with
>> -EINVAL and provide a way for callers to test whether this flag is possible.
> 
> Uhm, we might want to make "support_memmap_on_memory" public, and
> callers who might want to it use can check its return value?
> Or do you have something else in mind?

Right, a way for callers to check if it's supported. 
"mhp_supports_memmap_on_memory" or sth. like that.

Thanks!

-- 
Thanks,

David / dhildenb