CVS commit: src

["Taylor R Campbell" <riastradh%netbsd.org@localhost>]

Module Name:    src
Committed By:   riastradh
Date:           Thu Oct  1 22:23:57 UTC 2026

Modified Files:
        src/distrib/sets/lists/debug: mi
        src/distrib/sets/lists/tests: mi
        src/tests/kernel: Makefile
Added Files:
        src/tests/kernel: t_fdpass.c

Log Message:
cmsg: Test edge case of fd-passing near buffer size.

This test allows sendmsg to fail with ENOBUFS without blocking, and
verifies that the fds are received if it succeeds.

When passing file descriptors, sendmsg can fail with ENOBUFS it did
not or would not block because _after_ the blocking criterion is
tested in the AF-generic uipc_socket.c logic (essentially, whether
the data length + control length would exceed the send buffer size),
the control buffer is expanded on some architectures by converting
each int file descriptor to a struct file pointer in the kernel, and
then the buffer size is checked again in AF_LOCAL-specific logic when
unp_send calls sbappendcontrol.

Frankly I think this is a bad design, and sendmsg should just not
fail for this reason if it has passed the blocking criterion: either

(a) the AF_LOCAL-specific logic should count the user's control
    buffer size with ints rather than the the kernel's control buffer
    size with struct file pointers (which would mean the user can
    occupy a little more kernel memory than they could before, but
    it's limited by maxfiles/unp_rights_ratio times the difference in
    sizeof(int) and sizeof(struct file *) anyway); or

(b) the AF-generic logic should count the kernel's control buffer
    size (which would mean sendmsg might block before data length +
    control length reaches sndbuf, from the user's perspective, so
    I'm inclined to do the other option).

But it is _definitely_ wrong for sendmsg to report success when the
receiver cannot possibly receive the fds, and _less_ wrong for
sendmsg to report ENOBUFS in this case.

PR kern/60832: AF_LOCAL stream: sendmsg() with SCM_RIGHTS silently
drops data and descriptors but reports success


To generate a diff of this commit:
cvs rdiff -u -r1.520 -r1.521 src/distrib/sets/lists/debug/mi
cvs rdiff -u -r1.1431 -r1.1432 src/distrib/sets/lists/tests/mi
cvs rdiff -u -r1.102 -r1.103 src/tests/kernel/Makefile
cvs rdiff -u -r0 -r1.1 src/tests/kernel/t_fdpass.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.