Date: Fri, 26 Nov 2021 21:51:52 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 260055] recvmsg / IP_RECVDSTADDR issue Message-ID: <bug-260055-227-ws4gVRtJ9B@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-260055-227@https.bugs.freebsd.org/bugzilla/> References: <bug-260055-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260055 --- Comment #3 from Konstantin Belousov <kib@FreeBSD.org> --- > Maybe there is some application logic error if some payload data is disca= rded, > but recvmsg() still has control message to return because of IP_RECVDSTAD= DR > socket option, hasn't it? So it should not block just after first UDP dat= agramm > arrived, I believe. No, this is completely off how the control messages work. You do not have control message 'sit' in the socket buffer. CMSG is generated _on the pack= et insertion into the sockbuf queue_. On receive, associated cmsg is either externalized and copied out, if cmsg buffer is provided by userspace, or simply dropped. So the behavior you see is probably right (I cannot assert if fully because I do not know app logic and protocol): you have blocked socket, which somet= imes happens to have empty receive queue, and you call recvmsg(2) on it. Until something is received, the syscall is blocked. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-260055-227-ws4gVRtJ9B>