Date: Fri, 06 Apr 2018 14:10:15 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 227259] accept()/poll() and shutdown()/close() - not work as in FreeBSD10, may broke many apps Message-ID: <bug-227259-227-iB9LQ1i2jE@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-227259-227@https.bugs.freebsd.org/bugzilla/> References: <bug-227259-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=3D227259 --- Comment #9 from Jonathan T. Looney <jtl@freebsd.org> --- My best guess is that this is due to a new check in soshutdown() added in stable/11: sys/kern/uipc_socket.c: 2351 if ((so->so_state & 2352 (SS_ISCONNECTED | SS_ISCONNECTING | SS_ISDISCONNECTING)= ) =3D=3D 0) { 2353 /* 2354 * POSIX mandates us to return ENOTCONN when shutdown(2) is 2355 * invoked on a datagram sockets, however historica= lly we would 2356 * actually tear socket down. This is known to be leveraged by 2357 * some applications to unblock process waiting in recvXXX(2) 2358 * by other process that it shares that socket with. Try to meet 2359 * both backward-compatibility and POSIX requiremen= ts by forcing 2360 * ENOTCONN but still asking protocol to perform pru_shutdown(). 2361 */ 2362 if (so->so_type !=3D SOCK_DGRAM) 2363 return (ENOTCONN); 2364 soerror_enotconn =3D 1; 2365 } I don't think I ever really considered someone calling shutdown() on a listening socket. I would have expected them to use close(). My guess is th= at whoever added this didn't consider that case, either. FWIW, this check was added in r285910. I suppose the simple fix is to add a check for SOLISTENING(so) (head) or so->so_options & SO_ACCEPTCON (stable/11). However, we should consult with someone to see what POSIX requires in this case. --=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-227259-227-iB9LQ1i2jE>