PR/60832 CVS commit: [netbsd-11] src

["Martin Husemann" <martin%netbsd.org@localhost>]

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

From: "Martin Husemann" <martin%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/60832 CVS commit: [netbsd-11] src
Date: Sat, 24 Oct 2026 15:47:22 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sat Oct 24 15:47:22 UTC 2026
 
 Modified Files:
 	src/distrib/sets/lists/debug [netbsd-11]: mi
 	src/distrib/sets/lists/tests [netbsd-11]: mi
 	src/sys/kern [netbsd-11]: uipc_socket2.c uipc_usrreq.c
 	src/tests/kernel [netbsd-11]: Makefile
 Added Files:
 	src/tests/kernel [netbsd-11]: t_fdpass.c
 
 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #547):
 
 	tests/kernel/t_fdpass.c: revision 1.1
 	tests/kernel/t_fdpass.c: revision 1.2
 	tests/kernel/t_fdpass.c: revision 1.3
 	tests/kernel/t_fdpass.c: revision 1.4
 	distrib/sets/lists/debug/mi: revision 1.521
 	sys/kern/uipc_socket2.c: revision 1.149
 	tests/kernel/Makefile: revision 1.103
 	sys/kern/uipc_usrreq.c: revision 1.211
 	distrib/sets/lists/tests/mi: revision 1.1432
 
 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
 
 sendmsg(2): Report ENOBUFS instead of success on failure to pass fds.
 
 PR kern/60832: AF_LOCAL stream: sendmsg() with SCM_RIGHTS silently
 drops data and descriptors but reports success
 
 sendmsg(2): Treat ENOBUFS on fd passing as a bug.
 
 PR kern/60832: AF_LOCAL stream: sendmsg() with SCM_RIGHTS silently
 drops data and descriptors but reports success
 
 sendmsg(2): Don't fail with ENOBUFS on fd passing.
 
 We don't fail with ENOBUFS if we're not fd-passing -- we just block
 or fail earlier on with EAGAIN; no reason to invent a new failure
 mode just for the fd-passing case.
 
 Whether we should have _any_ path that checks the receiving socket's
 receive buffer limit is another question, but it's silly for it to:
 
 1. apply _only_ when passing fds,
 2. trip only when the kernel internally expands the buffer, and/or
 3. fail with ENOBUFS instead of blocking or failing with EAGAIN.
 
 This change essentially matches FreeBSD's subversion r337328:
 commit 5b0480f2cca0a4a04f21055ed769be93f11348de
 Author: Mark Johnston <markj%FreeBSD.org@localhost>
 Date:   Sat Aug 4 20:26:54 2018 +0000
 
     Don't check rcv sockbuf limits when sending on a unix stream socket.
     sosend_generic() performs an initial comparison of the amount of data
     (including control messages) to be transmitted with the send buffer
     size. When transmitting on a unix socket, we then compare the amount
     of data being sent with the amount of space in the receive buffer size;
     if insufficient space is available, sbappendcontrol() returns an error
     and the data is lost.  This is easily triggered by sending control
     messages together with an amount of data roughly equal to the send
     buffer size, since the control message size may change in uipc_send()
     as file descriptors are internalized.
     Fix the problem by removing the space check in sbappendcontrol(),
     whose only consumer is the unix sockets code.  The stream sockets code
     uses the SB_STOP mechanism to ensure that senders will block if the
     receive buffer fills up.
     PR:             181741
     MFC after:      1 month
     Sponsored by:   The FreeBSD Foundation
     Differential Revision:  https://reviews.freebsd.org/D16515
 
 https://cgit.freebsd.org/src/commit/?id=5b0480f2cca0a4a04f21055ed769be93f11348de
 
 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.485.2.14 -r1.485.2.15 src/distrib/sets/lists/debug/mi
 cvs rdiff -u -r1.1387.2.14 -r1.1387.2.15 src/distrib/sets/lists/tests/mi
 cvs rdiff -u -r1.147 -r1.147.2.1 src/sys/kern/uipc_socket2.c
 cvs rdiff -u -r1.209 -r1.209.2.1 src/sys/kern/uipc_usrreq.c
 cvs rdiff -u -r1.96.2.3 -r1.96.2.4 src/tests/kernel/Makefile
 cvs rdiff -u -r0 -r1.4.2.2 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.