769 static int 770 sendit(td, s, mp, flags) 771 struct thread *td; 772 int s; 773 struct msghdr *mp; 774 int flags; 775 { ... 796 if (mp->msg_control) { 797 if (mp->msg_controllen < sizeof(struct cmsghdr) 798 #ifdef COMPAT_OLDSOCK 799 && mp->msg_flags != MSG_COMPAT 800 #endif 801 ) { 802 error = EINVAL; 803 goto bad; 804 } The behavior on line 802 is not documented anywhere in send(2). It was driving me nuts trying to figure out what was going on in tools/regression/unix_cmsg:t_cmsg_len because the test fails on amd64 because that conditional is tripped -_-...
A commit references this bug: Author: ngie Date: Sat Jan 23 22:49:14 UTC 2016 New revision: 294646 URL: https://svnweb.freebsd.org/changeset/base/294646 Log: Don't run the t_cmsg_len testcase on 64-bit architectures It always fails when trying to send through the sendit(9) private KPI in the kernel due to a size mismatch between the msghdr and data being sent [*], which suspiciously seems like it's related to sizeof pointers instead of scalars, or something of that ilk MFC after: 1 week PR: 206543, 206544 [*] Sponsored by: EMC / Isilon Storage Division Changes: _U head/ head/tools/regression/sockets/unix_cmsg/unix_cmsg.c
Reporter is Committer, assign accordingly. @Ngie, please set mfc-* flags to + once they are committed in those branches. Don't forget to include the relevant PR: line :)
(In reply to Kubilay Kocak from comment #2) Hi koobs@! The change I proposed isn't going to fix the missing documentation. I can add it later (will remain CCed on the bug), but I want to start a quick discussion first with appropriate parties. Reassigning to freebsd-net and removing "In Progress" :).
(In reply to NGie Cooper from comment #3) Ah thanks. Could you then update (terse'ify) the summary to describe either: * A summary of the 'issue', OR * A summary of the action/fix/change that is needed That way we can annotate/classify the issue accordingly. Am I understanding correctly that r294646 referenced in comment 1 was to temporarily disable a test due to the issue described here, until its resolved, by a change (patch) that will be added here in due course?
Bug 206543 is tracking the test issue. I've updated the description to be more terse :).
MARKED AS SPAM
I've bumped into the lack of documentation as well, though the triggers were hidden far more deeply in the kernel: 1) An incorrect cmsg_len will typically trigger EINVAL. 2) Using IPv6-level messages (i.e. cmsg_level==IPPROTO_IPV6) with at IPv4-mapped IPv6 connection will trigger EINVAL in at least some cases. This appears to be a duplicate of bug 99356. I won't close it as a duplicate because there's different analysis in both bugs.