I was showing our magnificent pinsyscalls(2) framework to students last week.

One question that came up: why is there a |MZERO
in the malloc for the pins table (around line 360 of uvm_mmap.c)

Digging thru the commit history shows one single commit by Theo.

As far as I can tell, the next copyin will copy over the full allocation 
anyway (exact same size).

The only possible explanation I could fathom is that malloc will round up
the allocation size, thus there might be data in the roundup area from the
last allocation.

But, as far as I can tell, M_PINSYSCALL is only used by that subsystem,
so any remains would have to come from a previous allocation corresponding
to a process that no longer exist.

Either that process was statically linked, and the pins table is likely
to be much smaller, or the process is dynamically linked, in which the
table will be maxsize.

The only case where I actually see a potential problem is when you have
several libcs with a differing number of syscalls on the system, where 
rounded up allocations *might* leak offsets to the recently added 
syscalls as opposed to the (mostly fixed) array of classic syscalls.

Is this the reason for the MZERO ?