From owner-freebsd-current@FreeBSD.ORG Sat Mar 25 18:20:38 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3969E16A41F for ; Sat, 25 Mar 2006 18:20:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A26B943D45 for ; Sat, 25 Mar 2006 18:20:37 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8559B46BE6 for ; Sat, 25 Mar 2006 13:20:36 -0500 (EST) Date: Sat, 25 Mar 2006 18:20:36 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20060325181729.O88377@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: HEADS UP: netipx/spx changes (Re: cvs commit: src/sys/netipx ipx_pcb.c ipx_pcb.h ipx_usrreq.c spx_usrreq.c (fwd)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2006 18:20:38 -0000 This is to let -CURRENT users who are running with IPX/SPX support compiled into their kernel that I've recently committed substantial rewrites of portions of the netipx code. This is part of a larger reworking of the socket and protocol reference models, and should close a lot of subtle race conditions and eliminate a lot of edge case bugs. However, it's a high risk change, and I'm not able to test all aspects of netipx operation, so there are likely new bugs in my changes. So be warned that you may run into problems, and please contact me ASAP so I can help resolve them. I ran into a few bugs in netipx that I've not yet fixed, including the one I comment on below regarding the behavior of the SPX code on socket close, which can result in loss of data. I'm going to investigate this further, but was a bit surprised to find out it was the case. Presumably the protocols running on top of SPX are doing explicit acknowledgement, so perhaps this is not a problem in practice. Robert N M Watson ---------- Forwarded message ---------- Date: Sat, 25 Mar 2006 17:38:15 +0000 (GMT) From: Robert Watson To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netipx ipx_pcb.c ipx_pcb.h ipx_usrreq.c spx_usrreq.c On Sat, 25 Mar 2006, Robert Watson wrote: > Rework IPX/SPX socket and pcb reference model: > > - Introduce invariant that all IPX/SPX sockets will have valid so_pcb > pointers to ipxpcb structures, and that for SPX, the control block > pointer will always be valid. Don't attempt to free the socket or > pcb at various odd points, such as disconnect. > > - Add a new ipxpcb flag, IPXP_DROPPED, which will be set in place of > freeing PCB's so that this invariant can be maintained. This flag > is now checked instead of a NULL check in various socket protocol > calls. > > - Introduce many assertions that this invariant holds. > > - Various pieces of code, such as the SPX timer code, no longer needs > to jump through hoops in case it frees a PCB while running. > > - Break out ipx_pcbfree() from ipx_pcbdetach(). Likewise > spx_pcbdetach(). > > - Comment on some SMP-related limitations to the SPX code. > > - Update copyrights. The SPX code seems not to properly implement having data sent via a socket be transmitted after the socket is closed, so attempting to use SPX without so_linger is actually not very reliable. I'm not sure why this is the case, and may investigate fixing it, but was surprised to find this was the case. Robert N M Watson