aboutsummaryrefslogtreecommitdiff
path: root/lib/test_fortify/write_overflow-memcpy.c
diff options
context:
space:
mode:
authorOscar Salvador <[email protected]>2022-04-11 09:49:34 +0200
committerMichael Ellerman <[email protected]>2022-05-22 15:58:30 +1000
commit48b63961c84671df4c4a4451c40057e34b26df1a (patch)
treedd208eeed7027b28ba46b2ed06b33e15a49faebe /lib/test_fortify/write_overflow-memcpy.c
parent9a9c5ff5fff87eb1a43db0d899473554e408fd7b (diff)
powerpc/numa: Associate numa node to its cpu earlier
powerpc is the only platform that do not rely on cpu_up()->try_online_node() to bring up a numa node, and special cases it, instead, deep in its own machinery: dlpar_online_cpu find_and_online_cpu_nid try_online_node This should not be needed, but the thing is that the try_online_node() from cpu_up() will not apply on the right node, because cpu_to_node() will return the old mapping numa<->cpu that gets set on boot stage for all possible cpus. That can be seen easily if we try to print out the numa node passed to try_online_node() in cpu_up(). The thing is that the numa<->cpu mapping does not get updated till a much later stage in start_secondary: start_secondary: set_numa_node(numa_cpu_lookup_table[cpu]) But we do not really care, as we already now the CPU <-> NUMA associativity back in find_and_online_cpu_nid(), so let us make use of that and set the proper numa<->cpu mapping, so cpu_to_node() in cpu_up() returns the right node and try_online_node() can do its work. Signed-off-by: Oscar Salvador <[email protected]> Tested-by: Geetika Moolchandani <[email protected]> Reviewed-by: Srikar Dronamraju <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'lib/test_fortify/write_overflow-memcpy.c')
0 files changed, 0 insertions, 0 deletions