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: Sat, 24 Oct 2026 18:22:23 +0200 (CEST)

 >  Can you dump uvm.bucketcount in DDB ?
 
 If possible, I prefer not to have to shut down this host to do
 that.  Is there something I can dig out of the running 10.0
 system which would give us that information?
 
 But if there is no other way...
 
 
 Looking at various header files:
 
 #define VM_NFREELIST            6
 ...
 struct uvm {
         /* vm_page related parameters */
 
                 /* vm_page queues */
         struct pgfreelist page_free[VM_NFREELIST]; /* unallocated pages */
         u_int   bucketcount;
         bool    page_init_done;         /* true if uvm_page_init() finished */
 
                 /* page daemon trigger */
         int pagedaemon;                 /* daemon sleeps on this */
         struct lwp *pagedaemon_lwp;     /* daemon's lid */
 };
 
 ...
 extern struct uvm uvm;
 ...
 
 #define PGFL_MAX_BUCKETS        8
 struct pgfreelist {
         struct pgflbucket       *pgfl_buckets[PGFL_MAX_BUCKETS];
 };
 
 
 
 # crash
 Crash version 10.0, image version 10.0.
 Kernel compiled without options LOCKDEBUG.
 Output from a running system is unreliable.
 crash> p uvm
 ffffffff8190ecc0
 crash> x/x,4
 uvm:    d9b5e000    ffff82fa    d9b5e140    ffff82fa
 crash> 
 uvm+0x10:       0           0           0           0
 crash> 
 uvm+0x20:       0           0           0           0
 crash> 
 uvm+0x30:       0           0           0           0
 crash>
 crash> 
 uvm+0x40:       d9b5e280    ffff82fa    d9b5e3c0    ffff82fa
 crash> 
 uvm+0x50:       0           0           0           0
 crash> 
 uvm+0x60:       0           0           0           0
 crash> 
 uvm+0x70:       0           0           0           0
 crash> 
 uvm+0x80:       d9b5e500    ffff82fa    d9b5e640    ffff82fa
 crash> 
 uvm+0x90:       0           0           0           0
 crash> 
 uvm+0xa0:       0           0           0           0
 crash> 
 uvm+0xb0:       0           0           0           0
 crash> 
 uvm+0xc0:       d9b5e780    ffff82fa    d9b5e8c0    ffff82fa
 crash> 
 uvm+0xd0:       0           0           0           0
 crash> 
 uvm+0xe0:       0           0           0           0
 crash> 
 uvm+0xf0:       0           0           0           0
 crash> 
 uvm+0x100:      d9b5ea00    ffff82fa    d9b5eb40    ffff82fa
 crash> 
 uvm+0x110:      0           0           0           0
 crash> 
 uvm+0x120:      0           0           0           0
 crash> 
 uvm+0x130:      0           0           0           0
 crash> 
 uvm+0x140:      d9b5ec80    ffff82fa    d9b5edc0    ffff82fa
 crash> 
 uvm+0x150:      0           0           0           0
 crash> 
 uvm+0x160:      0           0           0           0
 crash> 
 uvm+0x170:      0           0           0           0
 crash> 
 uvm+0x180:      2           1           0           0
 crash> 
 
 So bucketcount = 2, at least in 10.0?
 
 and 10.0 probed the CPUs like this:
 
 : {31} dmesg | egrep 'cpu.*node'
 [     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
 : {32} 
 
 which seems to be identical to what 11.0 did.