Date: Tue, 04 Jul 2000 13:52:47 +0100 From: Kevin Bracey <kevin.bracey@pace.co.uk> To: freebsd-net@freebsd.org Subject: Race condition in TCP connection drops? Message-ID: <282ed4d849%kbracey@kbracey.cam.pace.co.uk>
next in thread | raw e-mail | index | archive | help
I've just come across a nasty glitch in our FreeBSD derived IP stack, and I'm curious to know whether the problem is inherent in the BSD network code, or is due to our implementation of its environment. I'm describing this from a version of the source from about 2 years ago, so some of the functions (eg xxx_usrreq) referred to will have changed, but as far as I can tell the recent changes haven't affected this particular problem. The problem occurs when a connection is dropped - tcp_drop() calls tcp_close(), which then does: free(tp, M_PCB); inp->inp_ppcb = 0; soisdisconnected(so); in_pcbdetach(inp); tcpstat.tcps_closed++; return ((struct tcpcb *)0); soisdisconnected() calls sowakeup(), which, because SS_ASYNC is set, calls psignal(). Now, on our system, psignal() sends round an immediate message, on receipt of which an application detects the failure and calls close() on the socket. Then, soclose calls tcp_usrreq(PRU_DETACH), which aborts because the inp_ppcb pointer is 0. This is totally reliable on our system, because the psignal mechanism is synchronous. Are there interlocks to prevent this happening on FreeBSD, or is it a race condition? I'm not as familiar as I perhaps should be with the Unix kernel environment. Is there a reason for soisdisconnected() to be called before in_pcbdetach()? -- Kevin Bracey, Principal Software Engineer Pace Micro Technology plc Tel: +44 (0) 1223 518566 645 Newmarket Road Fax: +44 (0) 1223 518526 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?282ed4d849%kbracey>