fix(classify): assign vmsplice to FamilyNetwork, not Misc

vmsplice(int fd, const struct iovec*, unsigned long nr_segs, unsigned int
flags) is the iovec<->pipe variant of splice(2) and belongs to the same fd
byte-mover cohort as its direct siblings splice/tee (and sendfile64/
copy_file_range). Its KIND (KindFd@arg0) and RET (TransferClassified, byte
count) already matched splice/tee — only the family was wrong.

Root cause: vmsplice was absent from the syscallFamilies map in
internal/generate/family.go; its name matches no fsNameMarkers and it is not
in fsSyscalls, so ClassifySyscallFamily fell through to FamilyMisc. This is
the same documented Misc-fall-through anti-pattern already fixed for
alarm/adjtimex/fanotify_init/fanotify_mark/file_getattr/file_setattr. The
established mj0 decision placed splice/tee in Network, so the minimal
sibling-consistent fix is vmsplice -> Network.

Added "vmsplice": FamilyNetwork next to splice/tee with an explanatory
comment, then re-ran `mage generate`. The regen is minimal and idempotent:
only the two vmsplice trace IDs flip Misc->Network in generated_types.go and
the vmsplice entry flips Misc->Network in generated_tracepoints.go; no
TraceId renumbering and no other syscalls change. The generated C tracepoints
are unaffected (family is a Go-side tag).

Also moved vmsplice from the Misc list to the Network list in
docs/syscall-tracing-plan.md (hand-maintained, docs-drift-validated), and
corrected the misc_test.go comments which described vmsplice as a Misc
syscall — it is still issued by the misc-basic workload and traced by name,
but its transfer/byte-count coverage lives in retbytes_test.go alongside
splice/tee. No vmsplice family assertion existed in the integration suite, so
no coverage was relocated, only comments corrected.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

1 files changed, 12 insertions, 1 deletions

diff --git a/internal/generate/family.go b/internal/generate/family.go
index 112a48f..1daca0f 100644
--- a/internal/generate/family.go
+++ b/internal/generate/family.go
@@ -27,7 +27,18 @@ var syscallFamilies = map[string]SyscallFamily{
 	"recvmmsg": FamilyNetwork, "recvmsg": FamilyNetwork, "sendfile64": FamilyNetwork,
 	"sendmmsg": FamilyNetwork, "sendmsg": FamilyNetwork, "sendto": FamilyNetwork,
 	"setsockopt": FamilyNetwork, "shutdown": FamilyNetwork, "socket": FamilyNetwork,
-	"socketpair": FamilyNetwork, "splice": FamilyNetwork, "tee": FamilyNetwork,
+	"socketpair": FamilyNetwork,
+	// splice/tee/vmsplice are the fd byte-mover cohort. splice moves data between
+	// two fds (one a pipe); tee duplicates pipe contents between pipe fds.
+	// vmsplice(int fd, const struct iovec*, unsigned long nr_segs, unsigned int
+	// flags) is the iovec<->pipe variant of splice(2) and is documented/grouped
+	// with splice/tee/sendfile64/copy_file_range as an fd byte-mover. Its KIND
+	// (KindFd@arg0) and RET (TransferClassified, byte count) already match
+	// splice/tee — only the family was wrong: vmsplice was absent from this map
+	// and fell through to FamilyMisc (the same alarm/adjtimex-style misclassi-
+	// fication fixed for fanotify_*/file_*attr). The established mj0 decision put
+	// splice/tee in Network, so for sibling consistency vmsplice belongs here too.
+	"splice": FamilyNetwork, "tee": FamilyNetwork, "vmsplice": FamilyNetwork,
 
 	"eventfd": FamilyIPC, "eventfd2": FamilyIPC,
 	// fanotify_init(2) creates and initializes an fanotify notification group and