mbox series

[0/2] x86/numa: Fix NUMA node overlap & init failure

Message ID cover.1705085543.git.alison.schofield@intel.com
Headers show
Series x86/numa: Fix NUMA node overlap & init failure | expand

Message

Alison Schofield Jan. 12, 2024, 8:09 p.m. UTC
From: Alison Schofield <alison.schofield@intel.com>

A previously posted single patch [1] is obsoleted by this set. The
feedback from that review is applied and noted in Patch 1.

While trying to attribute a CXL user report to the bad selection of
overlapping memblks, as fixed in Patch 1, I found that two issues,
in sequence, lead to NUMA Node overlap and NUMA init failure.

An overlapping NUMA node occurs when a non-overlapping memblk is
selected to fill (Patch 1), and then a bad sort (Patch 2) puts the
memblk with the greater address ahead of the lesser address memblk
in the fill list.

It looked like this:

Existing memblks:
	node 6 [mem 0xb90000000-0xc90000000]
	node 7 [mem 0xc90000000-0xd90000000]

Call to numa_fill_memblks(b90000000,c90000000)

Error (Patch 1): collects 2 blks  
	blk[0] node 6 [0xb90000000-0xc90000000]
	blk[1] node 7 [0xc90000000-0xd90000000]

Error (Patch 2): bad sort of the 2 blks
	blk[0] node 7 [0xc90000000-0xd90000000]
	blk[1] node 6 [0xb90000000-0xc90000000]

Seals the deal with a bad fill:
	blk[0] node 7 [0xb90000000-0xd90000000]

Boom: numa_clean_meminfo() discovers the overlap in Nodes 6 & 7
and NUMA init fails.

Since the scenario above is not solely attributed to either patch,
the story is explicity shared here.

[1] https://lore.kernel.org/linux-cxl/20240102213206.1493733-1-alison.schofield@intel.com/

Alison Schofield (2):
  x86/numa: Fix the address overlap check in numa_fill_memblks()
  x86/numa: Fix the sort compare func used in numa_fill_memblks()

 arch/x86/mm/numa.c       | 21 ++++++++-------------
 include/linux/memblock.h |  2 ++
 mm/memblock.c            |  5 +++--
 3 files changed, 13 insertions(+), 15 deletions(-)


base-commit: bd009225e8cbb6e18ad3389328fa640e4887dd9e

Comments

Dan Williams Jan. 12, 2024, 10:27 p.m. UTC | #1
alison.schofield@ wrote:
> From: Alison Schofield <alison.schofield@intel.com>
> 
> A previously posted single patch [1] is obsoleted by this set. The
> feedback from that review is applied and noted in Patch 1.
> 
> While trying to attribute a CXL user report to the bad selection of
> overlapping memblks, as fixed in Patch 1, I found that two issues,
> in sequence, lead to NUMA Node overlap and NUMA init failure.
> 
> An overlapping NUMA node occurs when a non-overlapping memblk is
> selected to fill (Patch 1), and then a bad sort (Patch 2) puts the
> memblk with the greater address ahead of the lesser address memblk
> in the fill list.
> 
> It looked like this:
> 
> Existing memblks:
> 	node 6 [mem 0xb90000000-0xc90000000]
> 	node 7 [mem 0xc90000000-0xd90000000]
> 
> Call to numa_fill_memblks(b90000000,c90000000)
> 
> Error (Patch 1): collects 2 blks  
> 	blk[0] node 6 [0xb90000000-0xc90000000]
> 	blk[1] node 7 [0xc90000000-0xd90000000]
> 
> Error (Patch 2): bad sort of the 2 blks
> 	blk[0] node 7 [0xc90000000-0xd90000000]
> 	blk[1] node 6 [0xb90000000-0xc90000000]
> 
> Seals the deal with a bad fill:
> 	blk[0] node 7 [0xb90000000-0xd90000000]
> 
> Boom: numa_clean_meminfo() discovers the overlap in Nodes 6 & 7
> and NUMA init fails.
> 
> Since the scenario above is not solely attributed to either patch,
> the story is explicity shared here.
> 
> [1] https://lore.kernel.org/linux-cxl/20240102213206.1493733-1-alison.schofield@intel.com/
> 
> Alison Schofield (2):
>   x86/numa: Fix the address overlap check in numa_fill_memblks()
>   x86/numa: Fix the sort compare func used in numa_fill_memblks()
> 
>  arch/x86/mm/numa.c       | 21 ++++++++-------------
>  include/linux/memblock.h |  2 ++
>  mm/memblock.c            |  5 +++--
>  3 files changed, 13 insertions(+), 15 deletions(-)

For both fixes:

Reviewed-by: Dan Williams <dan.j.williams@intel.com>

...if they get picked up into the x86 tree.

Otherwise I'll circle back and take them through cxl.git with an x86 ack
since this is all cxl-related fixups to numa_fill_memblks().
Dan Williams Jan. 25, 2024, 9:49 p.m. UTC | #2
Dan Williams wrote:
> alison.schofield@ wrote:
> > From: Alison Schofield <alison.schofield@intel.com>
> > 
> > A previously posted single patch [1] is obsoleted by this set. The
> > feedback from that review is applied and noted in Patch 1.
> > 
> > While trying to attribute a CXL user report to the bad selection of
> > overlapping memblks, as fixed in Patch 1, I found that two issues,
> > in sequence, lead to NUMA Node overlap and NUMA init failure.
> > 
> > An overlapping NUMA node occurs when a non-overlapping memblk is
> > selected to fill (Patch 1), and then a bad sort (Patch 2) puts the
> > memblk with the greater address ahead of the lesser address memblk
> > in the fill list.
> > 
> > It looked like this:
> > 
> > Existing memblks:
> > 	node 6 [mem 0xb90000000-0xc90000000]
> > 	node 7 [mem 0xc90000000-0xd90000000]
> > 
> > Call to numa_fill_memblks(b90000000,c90000000)
> > 
> > Error (Patch 1): collects 2 blks  
> > 	blk[0] node 6 [0xb90000000-0xc90000000]
> > 	blk[1] node 7 [0xc90000000-0xd90000000]
> > 
> > Error (Patch 2): bad sort of the 2 blks
> > 	blk[0] node 7 [0xc90000000-0xd90000000]
> > 	blk[1] node 6 [0xb90000000-0xc90000000]
> > 
> > Seals the deal with a bad fill:
> > 	blk[0] node 7 [0xb90000000-0xd90000000]
> > 
> > Boom: numa_clean_meminfo() discovers the overlap in Nodes 6 & 7
> > and NUMA init fails.
> > 
> > Since the scenario above is not solely attributed to either patch,
> > the story is explicity shared here.
> > 
> > [1] https://lore.kernel.org/linux-cxl/20240102213206.1493733-1-alison.schofield@intel.com/
> > 
> > Alison Schofield (2):
> >   x86/numa: Fix the address overlap check in numa_fill_memblks()
> >   x86/numa: Fix the sort compare func used in numa_fill_memblks()
> > 
> >  arch/x86/mm/numa.c       | 21 ++++++++-------------
> >  include/linux/memblock.h |  2 ++
> >  mm/memblock.c            |  5 +++--
> >  3 files changed, 13 insertions(+), 15 deletions(-)
> 
> For both fixes:
> 
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> 
> ...if they get picked up into the x86 tree.
> 
> Otherwise I'll circle back and take them through cxl.git with an x86 ack
> since this is all cxl-related fixups to numa_fill_memblks().

Circling back to check on these now that Mike has acked the memblock usage.
Dave or Peter, please pull them into tip/x86/mm, or I can circle back and grab
them next week.
Dave Hansen Jan. 29, 2024, 11 p.m. UTC | #3
On 1/25/24 13:49, Dan Williams wrote:
> Circling back to check on these now that Mike has acked the memblock usage.
> Dave or Peter, please pull them into tip/x86/mm, or I can circle back and grab
> them next week.

Hi Dan,

Feel free to carry these:

Acked-by: Dave Hansen <dave.hansen@linux.intel.com>