HEADS UP: netipx/spx changes (Re: cvs commit: src/sys/netipx ipx_pcb.c ipx_pcb.h ipx_usrreq.c spx_usrreq.c (fwd))

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 <rwatson_at_FreeBSD.org>
To: src-committers_at_FreeBSD.org, cvs-src_at_FreeBSD.org, cvs-all_at_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