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: <ef441868-9336-5cf4-5e5e-78dc3e3e8a96@redhat.com>
Date:   Mon, 6 Jul 2020 15:56:57 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Justin He <Justin.He@....com>,
        Catalin Marinas <Catalin.Marinas@....com>,
        Will Deacon <will@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Baoquan He <bhe@...hat.com>,
        Chuhong Yuan <hslester96@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Kaly Xin <Kaly.Xin@....com>
Subject: Re: [PATCH 1/3] arm64/numa: set numa_off to false when numa node is
 fake

On 06.07.20 14:36, Justin He wrote:
> Hi David, thanks for the comments. See my answer please:
> 
>> -----Original Message-----
>> From: David Hildenbrand <david@...hat.com>
>> Sent: Monday, July 6, 2020 4:03 PM
>> To: Justin He <Justin.He@....com>; Catalin Marinas
>> <Catalin.Marinas@....com>; Will Deacon <will@...nel.org>
>> Cc: Andrew Morton <akpm@...ux-foundation.org>; Mike Rapoport
>> <rppt@...ux.ibm.com>; Baoquan He <bhe@...hat.com>; Chuhong Yuan
>> <hslester96@...il.com>; linux-arm-kernel@...ts.infradead.org; linux-
>> kernel@...r.kernel.org; linux-mm@...ck.org; Kaly Xin <Kaly.Xin@....com>
>> Subject: Re: [PATCH 1/3] arm64/numa: set numa_off to false when numa node
>> is fake
>>
>> On 06.07.20 03:19, Jia He wrote:
>>> Previously, numa_off is set to true unconditionally in dummy_numa_init(),
>>> even if there is a fake numa node.
>>>
>>> But acpi will translate node id to NUMA_NO_NODE(-1) in
>> acpi_map_pxm_to_node()
>>> because it regards numa_off as turning off the numa node.
>>>
>>> Without this patch, pmem can't be probed as a RAM device on arm64 if
>> SRAT table
>>> isn't present.
>>>
>>> $ndctl create-namespace -fe namespace0.0 --mode=devdax --map=dev -s 1g -
>> a 64K
>>> kmem dax0.0: rejecting DAX region [mem 0x240400000-0x2bfffffff] with
>> invalid node: -1
>>> kmem: probe of dax0.0 failed with error -22
>>>
>>> This fixes it by setting numa_off to false.
>>>
>>> Signed-off-by: Jia He <justin.he@....com>
>>> ---
>>>  arch/arm64/mm/numa.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>>> index aafcee3e3f7e..7689986020d9 100644
>>> --- a/arch/arm64/mm/numa.c
>>> +++ b/arch/arm64/mm/numa.c
>>> @@ -440,7 +440,8 @@ static int __init dummy_numa_init(void)
>>>  		return ret;
>>>  	}
>>>
>>> -	numa_off = true;
>>> +	/* force numa_off to be false since we have a fake numa node here
>> */
>>> +	numa_off = false;
>>>  	return 0;
>>>  }
>>>
>>>
>>
>> What would happen if we use something like this in drivers/dax/kmem.c
>> instead:
>>
>> numa_node = dev_dax->target_node;
>> if (numa_node == NUMA_NO_NODE)
>> 	numa_node = memory_add_physaddr_to_nid(kmem_start);
>>
>> and eventually dropping the pr_warn in
>> arm64/memory_add_physaddr_to_nid() ? Would that work?
> 
> Yes, it works. I sent a similar patch [1] before. But seems pmem
> maintainer didn't satisfy it. Do you think memory_add_physaddr_to_nid()
> is better than numa_mem_id()? 

Well, it's the somewhat-common way to get a NID for memory hotadd.

E.g.,
- drivers/acpi/acpi_memhotplug.c
- drivers/base/memory.c
- drivers/hv/hv_balloon.c
- drivers/virtio/virtio_mem.c
- drivers/xen/balloon.c

use it in combination with add_memory_*()

Especially, ACPI and virtio-mem use it in case NUMA_NO_NID is detected.

-- 
Thanks,

David / dhildenb

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ