linux-kernel - Re: [PATCH 1/3] arm64/numa: set numa_off to false when numa node is fake

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: <20200706112921.00006f7f@Huawei.com>
Date:   Mon, 6 Jul 2020 11:29:21 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Jia He <justin.he@....com>
CC:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        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 Mon, 6 Jul 2020 09:19:45 +0800
Jia He <justin.he@....com> wrote:

Hi,

> 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.

That is correct.  It is operating exactly as it should, if SRAT hasn't been parsed
and you are on ACPI platform there are no nodes.  They cannot be created at
some later date.  The dummy code doesn't change this. It just does enough to carry
on operating with no specified nodes.

> 
> 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.

Without the SRAT protection patch [1] you may well run into problems
because someone somewhere will have _PXM in a DSDT but will
have a non existent SRAT.   We had this happen on an AMD platform when we
tried to introduce working _PXM support for PCI. [2]

So whilst this seems superficially safe, I'd definitely be crossing your fingers.
Note, at that time I proposed putting the numa_off = false into the x86 code
path precisely to cut out that possibility (was rejected at the time, at least
partly because the clarifications to the ACPI spec were not pubilc.)

The patch in [1] should sort things out however by ensuring we only create
new domains where we should actually be doing so. However, in your case
it will return NUMA_NO_NODE anyway so this isn't the right way to fix things.

[1] https://patchwork.kernel.org/patch/11632063/
[2] https://patchwork.kernel.org/patch/10597777/

Thanks,

Jonathan

> 
> 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;
>  }
>