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:	Thu, 31 Aug 2006 18:01:32 +0100 (IST)
From:	Mel Gorman <mel@....ul.ie>
To:	Mika Penttilä <mika.penttila@...umbus.fi>
Cc:	Keith Mannthey <kmannth@...il.com>, akpm@...l.org,
	tony.luck@...el.com,
	Linux Memory Management List <linux-mm@...ck.org>,
	ak@...e.de, bob.picco@...com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes

On Thu, 31 Aug 2006, Mika Penttilä wrote:

>
>>>> static __init inline int srat_disabled(void)
>>>> @@ -166,7 +167,7 @@ static int hotadd_enough_memory(struct b
>>>>
>>>>        if (mem < 0)
>>>>                return 0;
>>>> -       allowed = (end_pfn - e820_hole_size(0, end_pfn)) * PAGE_SIZE;
>>>> +       allowed = (end_pfn - absent_pages_in_range(0, end_pfn)) * 
>>>> PAGE_SIZE;
>>>>        allowed = (allowed / 100) * hotadd_percent;
>>>>        if (allocated + mem > allowed) {
>>>>                unsigned long range;
>>>> @@ -238,7 +239,7 @@ static int reserve_hotadd(int node, unsi
>>>>        }
>>>>
>>>>        /* This check might be a bit too strict, but I'm keeping it for 
>>>> now. */
>>>> -       if (e820_hole_size(s_pfn, e_pfn) != e_pfn - s_pfn) {
>>>> +       if (absent_pages_in_range(s_pfn, e_pfn) != e_pfn - s_pfn) {
>>>>                printk(KERN_ERR "SRAT: Hotplug area has existing 
>>>> memory\n");
>>>>                return -1;
>>>>        }
>>>> 
>>> We really do want to to compare against the e820 map at it contains
>>> the memory that is really present (this info was blown away before
>>> acpi_numa) 
>> 
>> The information used by absent_pages_in_range() should match what was
>> available to e820_hole_size().
>>
>> 
> But it doesn't : all active ranges are removed before parsing srat. I think 
> we really need to check against e820 here.
>

What I see happening is this;

1. setup_arch calls e820_register_active_regions(0, 0, -1UL) so that all
    regions are registered as if they were on node 0 so e820_end_of_ram()
    gets the right value
2. remove_all_active_regions() is called to clear what was registered so
    that rediscovery with NUMA awareness happens
3. acpi_numa_init() is called. It parses the table and a little later
    calls acpi_numa_memory_affinity_init() for each range in the table so
    now we're into x86_64 code
4. acpi_numa_memory_affinity_init() basically deals an address range.
    Assuming the SRAT table is not broken, it calls
    e820_register_active_ranges() for that range. At this point, for the
    range of addresses, the active ranges are now registered
5. reserve_hotadd is called if the range is hotpluggable. It will fail if
    it finds that memory already exists there

So, when absent_pages_in_range() is being called by reserve_hotadd(), it 
should be using the same information that was available in e820. What am I 
missing?

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ