[Bug 204438] setsockopt() handling of kern.ipc.maxsockbuf limit

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Tue Nov 10 18:17:53 UTC 2015


            Bug ID: 204438
           Summary: setsockopt() handling of kern.ipc.maxsockbuf limit
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: cameronsparr at gmail.com


I'd like to put out a proposal for changing the way that the setsockopt()
function handles the max socket buffer setting.

Currently, it's a bit unintuitive that socket send and receive buffers
(SO_RCVBUF & SO_SNDBUF) can not actually be set to the kern.ipc.maxsockbuf
value, even though it is described as being possible in the man page:

This is because setsockopt() will error out if the value passed is over the
_adjusted_ maximum, which on my system (amd64) turns out to be something like
kern.ipc.maxsockbuf * 0.889 (kern.ipc.maxsockbuf * (1 << 11) / (256 + (1 <<
11)) = kern.ipc.maxsockbuf * (2048) / (2304)).

see here:
and here:

I believe that the behavior could be made more intuitive by checking if the
value passed is under the _actual_ max before erroring out, and if it is under
the actual max, then set it to the adjusted max and continue the function, this
would be a simple change and would look something like this (apologies for the
whitespace diffs):

FWIW, the linux kernel takes it a step further by never failing if setting the
buffer over the maximum. It just takes whatever value it's given and sets it to
min(given_value, max_value). see here:
https://github.com/torvalds/linux/blob/master/net/core/sock.c#L762-L768. Not
saying this is a good option, just pointing out that there is a precedent for
doing something like this.

I would be happy to make this change and submit a patch to phabricator if

Thanks all,

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-bugs mailing list