schfs: the allocation map can be given back, so unmount stops leaking it

Started as "fix the ASAN leak in schfs_objtest" and the test turned out to be
the messenger. The allocation map was taken through a palloc callback and there
was no way to return it: no schfs_space_release, and a comment in
schfs_space_init reading "caller frees what was taken" for an API the caller
did not have.

Three separate leaks from that one gap:

  * The kernel leaked the entire map on every unmount -- up to 2 MB, at 8 KiB
    per GiB of volume -- because kmount_unmount flushed, cleared `mounted` and
    walked away. This is the one that matters; the others are test-only.
  * schfs_space_init stranded a page on its own error path. npages was raised
    only after *both* of a pair of allocations succeeded, so a failure on the
    second left the first outside the count -- unreachable to any cleanup that
    could later exist.
  * schfs_objtest leaked 2121728 bytes in 518 allocations, which is what made
    the whole SchFS suite exit non-zero regardless of its assertions.

The map now carries its own pfree rather than taking one at release time, so it
can only ever be freed by the allocator that filled it -- the kernel's pages
come from kalloc and a host tool's from calloc, and the two are not
interchangeable. schfs_vol_open and schfs_vol_format release any map the volume
is already holding before building another, which is what stops a re-open
leaking; struct schfs_vol must therefore be zeroed before first use, and the
header now says so.

The test's own leak was the last one found and the simplest: it does
memset(&VOL, 0, sizeof(VOL)) before reopening, which wiped the map's pointers
before vol_open could release them. Eight of those, each now releasing first.

schfs_objtest asserts the balance -- 520 pages taken, 520 given back -- because
a suite that leaks cannot detect a leak: the filesystem's own allocations would
arrive as noise inside the harness's. The next one fails the run instead.

make schfs-check now exits 0. The 31 UBSAN misalignment reports are still
there and are still a Gate 0 item.

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

kernel/fs/schfs/kmount.c

@@ -447,6 +447,15 @@ kd_palloc(void)
   return kalloc();
 }
 
+// The other half of kd_palloc, and the reason unmount stopped leaking: the
+// allocation map is up to SCHFS_SPACE_PAGES pages of kalloc'd memory, and
+// nothing ever gave it back. A mount/unmount cycle leaked the lot.
+static void
+kd_pfree(void *p)
+{
+  kfree((char *)p);
+}
+
 // Mount the SchFS volume on block device `bdev` into slot `slot`.
 //
 // Never panics: a disk that is not SchFS, or is an unreadable SchFS, simply
@@ -495,7 +504,7 @@ kmount_slot(int slot, uint bdev)
   // Opening with a page allocator also builds the allocation bitmap, by walking
   // the tree — the only mount-time cost SchFS has, and what buys it a mount
   // that cannot disagree with the filesystem it just adopted.
-  int r = schfs_vol_open(&m->vol, &bd, &cx, kd_palloc);
+  int r = schfs_vol_open(&m->vol, &bd, &cx, kd_palloc, kd_pfree);
   if (r == -1)
     return -EINVAL;              /* not a SchFS volume at all */
   if (r == -4) {
@@ -594,6 +603,10 @@ schfs_kumount(uint dev)
 
   acquiresleep(&m->lock);
   bflush(m->kdev.dev);
+  // Give the allocation map back. It is rebuilt from the tree on every mount,
+  // so there is nothing in it worth keeping -- and at 8 KiB per GiB of volume,
+  // keeping it was the largest thing this kernel leaked.
+  schfs_space_release(&m->vol.space);
   m->mounted = 0;
   releasesleep(&m->lock);
   return 0;