linux-kernel - Re: memblock vs early

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]

Message-ID: <4C93F5B6.4050508@goop.org>
Date:	Fri, 17 Sep 2010 16:11:50 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Ingo Molnar <mingo@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>
Subject: Re: memblock vs early_res

 On 09/17/2010 03:47 PM, Yinghai Lu wrote:
> On 09/17/2010 01:47 PM, Jeremy Fitzhardinge wrote:
>>  Hi Yinghai,
>>
>> I have the patch below floating around in my tree to make sure that
>> early-reserved highmem is honoured when freeing unreserved memory.  I
>> was trying to rebase it to current linux-next and noticed that all the
>> early_res stuff has been replaced with memblock.
>>
>> Is this still an issue?  What would the memblock version of this patch
>> look like?
>>
> Not sure why this patch is needed.
>
> For the early reserve ranges, that could be overlapped with high pages, is "KVA RAM",
> but We do remove those range in active ranges array. [ in calculate_numa_remap_pages() ].
> [
> ...
>                 memblock_x86_reserve_range(node_kva_final,
>                               node_kva_final+(((u64)size)<<PAGE_SHIFT),
>                               "KVA RAM");
>
>                 node_remap_start_pfn[nid] = node_kva_final>>PAGE_SHIFT;
>                 remove_active_range(nid, node_remap_start_pfn[nid],
>                                          node_remap_start_pfn[nid] + size);
> ...
> ]
>
> Can you check if Gianluca Guida still can duplicate the problem that will need his patch ?

The specific motivation for this patch is to handle Xen ballooning where
the domain can be built with X pages of memory available to it
initially, but Y pages are presented in the E820 map (Y >= X).  The
extra pages in the E820 are not physically present, but I want the
kernel to allocate page structures for them, so I reserve_early() them
to stop them from being used.  Later on, the balloon driver can
incrementally populate these pfns and return them to the kernel for use
as real memory.

Without this patch, the reservations of the highmem pages are ignored
and the kernel ends up trying to use these non-resident pages.  (At
least that's what used to happen, and I didn't see any changes which
looked like they would address this.)

Does the code you quote above address this case?

Thanks,
    J
--
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/