CVS commit: [netbsd-10] src

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

Module Name:    src
Committed By:   martin
Date:           Sat Oct 24 15:50:24 UTC 2026

Modified Files:
        src/distrib/sets/lists/debug [netbsd-10]: mi
        src/distrib/sets/lists/tests [netbsd-10]: mi
        src/sys/kern [netbsd-10]: uipc_socket2.c uipc_usrreq.c
        src/tests/kernel [netbsd-10]: Makefile
Added Files:
        src/tests/kernel [netbsd-10]: t_fdpass.c

Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1392):

        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
        (all via patch)

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.394.2.21 -r1.394.2.22 src/distrib/sets/lists/debug/mi
cvs rdiff -u -r1.1238.2.27 -r1.1238.2.28 src/distrib/sets/lists/tests/mi
cvs rdiff -u -r1.142 -r1.142.2.1 src/sys/kern/uipc_socket2.c
cvs rdiff -u -r1.203.4.1 -r1.203.4.2 src/sys/kern/uipc_usrreq.c
cvs rdiff -u -r1.70.2.3 -r1.70.2.4 src/tests/kernel/Makefile
cvs rdiff -u -r0 -r1.4.4.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.