Re: port-amd64/60920: 11.0 kernel for amd64 fails with null pointer deref in uvm_page_redim()

["Havard Eidnes via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-amd64/60920; it has been noted by GNATS.

From: Havard Eidnes <he%NetBSD.org@localhost>
To: gnats-bugs%netbsd.org@localhost, gnats-admin%NetBSD.org@localhost
Cc: port-amd64-maintainer%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: port-amd64/60920: 11.0 kernel for amd64 fails with null
 pointer deref in uvm_page_redim()
Date: Sun, 25 Oct 2026 13:52:04 +0100 (CET)

 >  >So those show numa_id 0, 1, 2 and 3 (in reverse order)?
 >
 >  >But why doesn't 10.0 fail, but 11.0 does?
 >
 >  Maybe -11 clears the array and the stack value is a
 >  "valid" pointer (to something else, but that doesn't
 >  cause a crash)?
 
 That sounds somewhat implausible...
 
 >  In any case, with 4 NUMA nodes, you need at least 4 buckets
 >  and not 2. Or you also have to reduce the numa-id modulo bucket count.
 
 Well, I've looked around a bit, and despite this being an area above
 my paygrade, let me share a few observations, even though I have not
 found the explanation for why 11.0 fails but 10.0 succeeds on this
 hardware.
 
 There is the uvm_page_rebucket() function which is supposed to heed
 NUMA-based bucket allocation as long as the number of NUMA IDs is
 less than PGFL_MAX_BUCKETS, which appears to be 8, and that is done
 via
 
                 aprint_debug("UVM: using NUMA allocation scheme\n");
 ...
                 uvm_page_redim(uvmexp.ncolors, max_numa + 1);
                 return;
 
 How do I get that debug printout?  Does the kernel need to be compiled
 with the DEBUG option set, or is it just a matter of supplying the
 right option to the "boot" command in the bootloader?  Perhaps the
 "-x" option?
 
 And uvm_page_rebucket() is called from kern/init_main.c's configure2()
 function, and that appears to be done both in 10.0 and 11.0.
 
 But, hmm, x86's cpu_vm_init() calls
 
         aprint_debug_dev(ci->ci_dev, "%d page colors\n", ncolors);
         uvm_page_recolor(ncolors);
 
 and uvm_page_recolor() is just a wrapper around uvm_page_redim().
 
 But cpu_vm_init() does not appear to take the number of NUMA nodes in
 the system into account when calculating ncolors, but instead just
 looks at the caches on the (single?!?) CPU and their associativity?
 But ... by the looks of it, this is the same in both 10.0 and 11.0
 sources.
 
 >  As a crude workaround you might be able to disable NUMA
 >  in the BIOS.
 
 I thought that the presence or absence of NUMA was a characteristic of
 the actual hardware, and not something which can be turned on or off?
 
 Besides, this is a regression, so I'd prefer we find a "proper fix".
 
 
 BTW, the asymmetry I find confusing:
 
 [     1.000004] cpu0: node 0, package 0, core 0, smt 0
 [     1.000004] cpu1: node 0, package 0, core 1, smt 0
 [     1.000004] cpu2: node 0, package 0, core 2, smt 0
 [     1.000004] cpu3: node 0, package 0, core 3, smt 0
 [     1.000004] cpu4: node 0, package 0, core 4, smt 0
 [     1.000004] cpu5: node 0, package 0, core 5, smt 0
 [     1.000004] cpu6: node 0, package 0, core 6, smt 0
 [     1.000004] cpu7: node 0, package 0, core 7, smt 0
 [     1.000004] cpu8: node 0, package 1, core 0, smt 0
 [     1.000004] cpu9: node 0, package 1, core 1, smt 0
 [     1.000004] cpu10: node 0, package 1, core 2, smt 0
 [     1.000004] cpu11: node 0, package 1, core 3, smt 0
 [     1.000004] cpu12: node 1, package 1, core 4, smt 0
 [     1.000004] cpu13: node 1, package 1, core 5, smt 0
 [     1.000004] cpu14: node 1, package 1, core 6, smt 0
 [     1.000004] cpu15: node 1, package 1, core 7, smt 0
 
 So for package 0, all the 8 CPU cores are "on the same node", node 0.
 
 But for package 1, the first 4 CPU cores are on the same node as all
 the cores in package 0, but the last 4 CPU cores are on a "node" of
 itself?  Not being intimately familiar with the architecture at this
 level, I naively thoght that "node" came before "package" in the
 enumeration hierarchy, but evidently that is not the case.
 
 And a "package" is the same as a what I insert in a physical CPU
 socket, right?
 
 And ... how do we get from the above to 4 NUMA IDs?  So a NUMA ID is
 not the same as "node number"?
 
 Regards,
 
 - Havard