Date: Wed, 25 Jul 2018 20:07:32 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 181741] [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(2)) Message-ID: <bug-181741-7501-rWx3n0o51t@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-181741-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-181741-7501@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=3D181741 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markj@FreeBSD.org --- Comment #17 from Mark Johnston <markj@FreeBSD.org> --- I'm not sure I see much value in internalizing ("finalizing") control messa= ges in sosend_generic(). In general, the socket layer does not treat the sockb= uf limits (sb_mbmax and sb_hiwat) as strict limits; see the comment about SB_S= TOP in uipc_rcvd(), for example. Furthermore, the unix socket code never actua= lly puts anything in the send buffer. The purpose of the limits in this contex= t is to enable a somewhat rudimentary backpressure system, and since sosend_generic() already puts a hard bound on the size of control messages,= I don't see why it needs to go through the trouble of performing an exact che= ck. Assuming that argument is reasonable, I believe it's sufficient to just omit the space checks in sbappendcontrol() like we already do for SEQPACKET unix sockets. --=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-181741-7501-rWx3n0o51t>