debugger: who owns this page, and who just wrote to it

docs/plan/debugger.md D3 and D4, which finish the plan apart from the
network transport.

D3 -- `whose <addr>`. The views each speak for one subsystem, which is what
keeps them cheap and current, and it is exactly why none of them can see
the bug that matters: a page on the DMA arena's free list looks fine from
dma.c, the same page on kalloc's free list looks fine from kalloc.c, and
that it is on both is a fact no single subsystem holds.

    # schdbg whose 0x3e239000
    phys 0x000000003e239000   kernel va 0xffff80003e239000
      dma     arena, handed out
      pcidma  slot 2, 0 KB into a 4000 KB block given to pid 4 (vgpud)
      mapped  pid 4 (vgpud) at 0x000000004000d000  rwu  vma[5] no_free

      consistent: 1 owner, 1 mapping(s)

Claimants register the way views do -- one line in the file that owns the
data -- so the kernel image, the log region, the arena, the page allocator,
the pciuser DMA blocks and every page table each answer for themselves.
`mapped` is the one no allocator can answer: there is no reverse map, so
vm_walk_user() goes forward over every mapped page of every live process.

Two verdicts are shouted and everything else is reported as fact. More than
one owner means the second allocator to hand the page out is handing out
memory the first is still using -- the H2 bug, which would have printed as
three lines. Free-but-still-mapped means a page will be given away from
under the page tables that point at it. Deliberately *not* a finding: no
owner at all, because kalloc keeps a free list and no record of what it has
handed out, so an ordinary allocated page has nobody to speak for it and
saying otherwise would be the query crying wolf.

D4 -- watchpoints, on the four debug registers that had been sitting unused
since this kernel was written. Armed against the same framebuffer page and
then killing the driver:

    watch 0: 0xffff80003e239000 written, 8 byte(s), by stosq+0x1f, pid 12 vgpud
             #0  memset+0xba
             #1  dma_alloc+0x2e2
             #2  do_dma+0x22a
             #3  pciuser_ioctl+0x13b
             #4  sys_ioctl+0x3c7
             #5  syscall+0xf6

The chain is the answer, not the rip. It reports and continues -- a data
watchpoint is a trap, delivered after the store completes, so returning
carries on with the program none the wiser, which is what lets this be used
on a machine that is still running.

Debug registers are per-CPU and there is no general IPI here, so the table
carries a generation number and each CPU reloads from its timer interrupt
when it notices the number has moved: one comparison per tick, one tick of
latency at worst. `watch` prints which CPUs have caught up, because "this
watchpoint is watching" and "this watchpoint is watching one CPU" must not
look the same.

Also fixed while testing: watch_init() was called from mpmain(), which runs
on every processor, so the command appeared in the list once per CPU.
dbg_register() now refuses a duplicate name outright, so the next init that
runs per-CPU fails loudly in the list rather than quietly doubling it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2

include/dbg.h

@@ -37,6 +37,33 @@ typedef void (*dbg_view_fn)(struct sbuf *out, const char *arg);
 // and needs no initialisation of its own.
 void dbg_register(const char *name, dbg_view_fn fn, const char *what);
 
+// --- whose <addr> -----------------------------------------------------------
+//
+// The query the views cannot answer between them: *who owns this page?*
+//
+// Each view speaks for one subsystem, which is what keeps them cheap and
+// current -- and it is exactly why none of them can see the bug that matters.
+// A page on the DMA arena's free list looks fine from dma.c. The same page on
+// kalloc's free list looks fine from kalloc.c. That it is on both is a fact no
+// single subsystem holds, and it is the bug that cost this project a day.
+//
+// So `whose` asks every subsystem about one page and counts the answers. The
+// contributors are registered the same way views are, for the same reason:
+// adding one is a line in the file that owns the data.
+
+struct whose {
+  uint64 phys;          // the page being asked about, page-aligned
+  uint64 off;           // how far into it the original address was
+  int    owners;        // allocators and reserved regions claiming it
+  int    free_owners;   // of those, how many believe it is unused
+  int    mappings;      // user page tables mapping it
+};
+
+typedef void (*dbg_whose_fn)(struct sbuf *out, struct whose *w);
+
+// Publish a claimant. `name` is the column it prints under.
+void dbg_register_whose(const char *name, dbg_whose_fn fn);
+
 // Run one command line and render the answer. Returns the number of bytes
 // written into `out`.
 //
@@ -46,6 +73,7 @@ void dbg_register(const char *name, dbg_view_fn fn, const char *what);
 //   help            what this kernel can be asked
 //   all             every view, in registration order
 //   <name> [arg]    that view, optionally narrowed
+//   whose <addr>    every subsystem's claim on one page
 int dbg_command(const char *line, struct sbuf *out);
 
 // Every view, straight to the console. This is what sysrq 'g' runs, and it is