PR/60832 CVS commit: src

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

The following reply was made to PR kern/60832; it has been noted by GNATS.

From: "Taylor R Campbell" <riastradh%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/60832 CVS commit: src
Date: Thu, 1 Oct 2026 22:23:57 +0000

 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.