Having an additional MT_HEADER mbuf type is superfluous and redundant
as nothing depends on it. It only adds a layer of confusion. The
distinction between header mbuf's and data mbuf's is solely done
through the m->m_flags M_PKTHDR flag.
Non-native code is not changed in this commit. For compatibility
MT_HEADER is mapped to MT_DATA.
Sponsored by: TCP/IP Optimization Fundraise 2005
following the protocol pru_listen() call to solisten_proto(), so
that it occurs under the socket lock acquisition that also sets
SO_ACCEPTCONN. This requires passing the new backlog parameter
to the protocol, which also allows the protocol to be aware of
changes in queue limit should it wish to do something about the
new queue limit. This continues a move towards the socket layer
acting as a library for the protocol.
Bump __FreeBSD_version due to a change in the in-kernel protocol
interface. This change has been tested with IPv4 and UNIX domain
sockets, but not other protocols.
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.
This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.
Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.
Reviewed by: sobomax, sam
the ipx_net data structure. Doing so introduced a stronger alignment
requirement for the address structure, which in turn propagated into
other dependent data structures, which turns out not to be suported by
the available IPX source code. As a result, a number of user space
applications, such as IPX routing components, failed to operate
correctly.
RELENG_5_3 candidate?
PRs: 74059, 80266
Pointy hat to: bms
Fix by: bde
Tested by: Keith White <Keith dot White at site dot uottawa dot ca>
MFC after: 1 week
Suffering: great
a socket from a regular socket to a listening socket able to accept new
connections. As part of this state transition, solisten() calls into the
protocol to update protocol-layer state. There were several bugs in this
implementation that could result in a race wherein a TCP SYN received
in the interval between the protocol state transition and the shortly
following socket layer transition would result in a panic in the TCP code,
as the socket would be in the TCPS_LISTEN state, but the socket would not
have the SO_ACCEPTCONN flag set.
This change does the following:
- Pushes the socket state transition from the socket layer solisten() to
to socket "library" routines called from the protocol. This permits
the socket routines to be called while holding the protocol mutexes,
preventing a race exposing the incomplete socket state transition to TCP
after the TCP state transition has completed. The check for a socket
layer state transition is performed by solisten_proto_check(), and the
actual transition is performed by solisten_proto().
- Holds the socket lock for the duration of the socket state test and set,
and over the protocol layer state transition, which is now possible as
the socket lock is acquired by the protocol layer, rather than vice
versa. This prevents additional state related races in the socket
layer.
This permits the dual transition of socket layer and protocol layer state
to occur while holding locks for both layers, making the two changes
atomic with respect to one another. Similar changes are likely require
elsewhere in the socket/protocol code.
Reported by: Peter Holm <peter@holm.cc>
Review and fixes from: emax, Antoine Brodin <antoine.brodin@laposte.net>
Philosophical head nod: gnn
structures in IPX/SPX -- primarily, sequence numbering, PCB lists,
and PCBs for IPX raw sockets, IPX datagram sockets, and IPX/SPX.
As such, remove remove NET_NEEDS_GIANT() for IPX, and remove the
assertion of Giant in the ipxintr() IPX input path.
Note that IPX/SPX is not fully MPSAFE, and that there are some
problems with IPX/SPX locking that will require some further work.
However, it is now safe enough to run in general without the Giant
lock.
MFC after: 4 weeks
portion of IPX/SPX:
- Protect IPX PCB lists with the IPX PCB list mutex, in particular
when calling PCB and PCB list manipulation routines in ipx_pcb.c.
- Protect both IPX PCB state and SPX PCB state using the IPX PCB
mutex.
- Generally annotate locking, as well as adding liberal use of lock
assertions to document locking requirements.
- Where possible, use unlocked reads when reading integer or smaller
sized socket options on SPX sockets.
- De-spl throughout.
Notes:
- spx_input() expects both the list mutex and PCB mutex to be held
on entry, but will release both on return. Because sonewconn() is
called from spx_input(), it may actually drop one PCB lock and
acquire another during generation of a new connection, meaning the
caller is not in a position to unlock the PCB mutex.
MFC after: 3 weeks
were derived from more complex TCP versions of the same:
- spx_close(), spx_disconnect(), spx_drop(), and spx_usrclosed() all
always free's the spxpcb invalidating the argument, so a return
value is not required to indicate if it has.
- Annotate that the cb arguments to each of these functions is
invalidated via a comment.
- When tearing down a pcb due to sonewconn() having failed, mark the
cb as NULL; later, when deciding whether to store trace information
due to SO_DEBUG, check that cb is not NULL before dereferencing or
a NULL pointer dereference may occur.
MFC after: 3 weeks
When processing socket options against IPX PCBs, generally protect
PCB fields using the IPX PCB mutex. Where possible, use unlocked
reads on integer values to avoid locking overhead.
MFC after: 3 weeks
protocol methods relating to IPX. Conditionally acquire the PCB list
lock in the send operation only if the socket requires binding in order
to use the requested address.
Remove spl's generally no longer required during these accesses.
MFC after: 3 weeks
the IPX-related PCB routines. In general, the list lock is required
to iterate the PCB list, either for read or write; the PCB lock is
required to access or modify a PCB. To change the binding of a PCB,
both locks must be held.
MFC after: 3 weeks
IPX PCB lists. Add macros to initialize, destroy, lock, unlock,
and assert the mutex. Initialize the mutex when IPX is started.
Add per-IPX PCB mutexes, ipxp_mtx in struct ipxpcb, to protect
per-PCB IPX/SPX state. Add macros to initialize, destroy, lock,
unlock, and assert the mutex. Initialize the mutex when a new
PCB is allocated; destroy it when the PCB is free'd.
MFC after: 2 weeks
spx_reass() to increase atomicity across multiple operations on the
socket buffer when iterating over the SPX fragment reassembly list
for the ipxpcb, as well a to reduce the number of locking operations.
record loop for ACK'd data, rather than relying on lokcing in
sbdroprecord() and sowwakeup(), reducing the number of lock operations
as well as eliminating a possible race against the head of the send
buffer mbuf chain. Use the _locked variants of sbdroprecord() and
sowwakeup().
the peer address by using M_WAITOK in ipx_setpeeraddr() to prevent
allocation failure. The socket reference used to reach these calls
will prevent the ipxpcb from being released prematurely.
properly handle the case where a connection is disconnected. The
queue(9)-enabled version of this code broke from the inner but not
outer loop, and so potentially frobbed an ipxpcb flag after the ipxpcb
was free'd, which might be picked up later by the malloc debugging
code. Properly break from the loop context and avoid touching the
cb/ipxpcb after free.
expects a locked route reference. This removes a panic that occurs
when connected ipxpcb is closed and its route free'd, and may have been
present since the route locking took place.
MFC after: 2 weeks
the netperf branch but for some reason didn't trigger a build failure
locally when I merged to CVS and omitted it. Presumably driver error.
Pointed out by: cperciva, tinderbox
- ipx_pcbnotify(), which is never called.
- ipx_rtchange(), which is never called, is incomplete inplemented, and
also #ifdef notdef.
- spx_fixmtu(), which is never called, is incompletely implemented, and
also #ifdef notdef.
