src/sys/netinet, branch releng/7.0

Fix errors in the padding of TCP options.

2008-06-19T06:36:10Z

Errata: FreeBSD-EN-08:02.tcp Approved by: so (cperciva)

Merge uipc_sockbuf.c:1.175, uipc_socket.c:1.304, uipc_syscalls.c:1.264,

2008-02-02T12:44:14Z

sctp_input.c:1.67, sctp_peeloff.c:1.17, sctputil.c:1.73, socketvar.h:1.161 from HEAD to RELENG_7_0: Correct two problems relating to sorflush(), which is called to flush read socket buffers in shutdown() and close(): - Call socantrcvmore() before sblock() to dislodge any threads that might be sleeping (potentially indefinitely) while holding sblock(), such as a thread blocked in recv(). - Flag the sblock() call as non-interruptible so that a signal delivered to the thread calling sorflush() doesn't cause sblock() to fail. The sblock() is required to ensure that all other socket consumer threads have, in fact, left, and do not enter, the socket buffer until we're done flushin it. To implement the latter, change the 'flags' argument to sblock() to accept two flags, SBL_WAIT and SBL_NOINTR, rather than one M_WAITOK flag. When SBL_NOINTR is set, it forces a non-interruptible sx acquisition, regardless of the setting of the disposition of SB_NOINTR on the socket buffer; without this change it would be possible for another thread to clear SB_NOINTR between when the socket buffer mutex is released and sblock() is invoked. Reviewed by: bz, kmacy, rrs Reported by: Jos Backus Approved by: re (kensmith)

- Fixes is a bug in sctp_auth that will cause a panic if

2008-01-31T17:21:50Z

a socket is closed as it gets auth'd data in. (sctp_auth.c) - Reverts the priority back to 0, do not change prioritys (sctp_bsd_addr.c) - Fixes a wrap error in calculation of gap ack segments that wrap the TSN number. (sctp_indata.c) - Fixes a comment, and also moves a lock up to cover the pulling of the VRF from the inp structure. (sctp_pcb.c) Approved by: re@freebsd.org (Ken Smith)

Merge ipfw2.c:1.113, ip_fw.h:1.111, ip_fw2.c:1.180 from HEAD to

2008-01-28T17:44:30Z

RELENG_7_0: Hide ipfw internal data structures behind IPFW_INTERNAL rather than exposing them to all consumers of ip_fw.h. These structures are used in both ipfw(8) and ipfw(4), but not part of the user<->kernel interface for other applications to use, rather, shared implementation. Reported by: Paul Vixie Approved by: re (kensmith)

Merge tcp_usrreq.c:1.167 from HEAD to RELENG_7_0:

2008-01-26T13:57:33Z

tcp_usrreq.c:1.130 removed tcbinfo locking from tcp_usr_accept(), which while in principle a good idea, opened us up to a race inherrent to the syncache's direct insertion of incoming TCP connections into the "completed connection" listen queue, as it transpires that the socket is inserted before the inpcb is fully filled in by syncache_expand(). The bug manifested with the occasional returning of 0.0.0.0:0 in the address returned by the accept() system call, which occurred if accept managed to execute tcp_usr_accept() before syncache_expand() had copied the endpoint addresses into inpcb connection state. Re-add tcbinfo locking around the address copyout, which has the effect of delaying the copy until syncache_expand() has finished running, as it is run while the tcbinfo lock is held. This is undesirable in that it increases contention on tcbinfo further, but a more significant change will be required to how the syncache inserts new sockets in order to fix this and keep more granular locking here. In particular, either more state needs to be passed into sonewconn() so that pru_attach() can fill in the fields *before* the socket is inserted, or the socket needs to be inserted in the incomplete connection queue until it is actually ready to be used. Reported by: glebius (and kris) Tested by: glebius Approved by: re (kensmith)

- sctp-iterator should run at PI_NET priority ...not 0.

2007-12-29T15:07:54Z

Approved by: re@freebsd.org(gnn)

Merge in_pcb.c:1.196.2.1 from RELENG_7 to RELENG_7_0:

2007-12-22T20:54:46Z

When IPSEC fails to allocate policy state for an inpcb, and MAC is in use, free the MAC label on the inpcb before freeing the inpcb. Submitted by: tanyong , zhouzhouyi Approved by: re (kensmith)

MFC: 1.141: Fix bugs in the TCP syncache timeout code.

2007-12-20T12:34:32Z

Approved by: re (kensmith)

MFC 1.334

2007-12-19T08:10:30Z

Approved by: re@freebsd.org

- Found a problem in non-blocking sends. When

2007-12-09T20:23:47Z

sending, once the locks are all unlocked to do the copy's in, its possible that other events could then raise the number of bytes outstanding pushing it so not all the message would fit. This would then cause us to send only part of the message. This fix makes it so we keep a "reserved" amount that can be kept in mind when making calculations to send. - rcv msg args with a NULL/NULL for to/tolen will return an error incorrectly for the 1-2-1 model. - We were not doing 0 len return correctly and not setting socantrcv() more correctly. Previouly we "fixed" this area by taking out the socantrcv() since we then could not get the data out. The correct fix is to still flag the socket but alow a by-pass route to continue to read until all data is consumed. - Fix the initial buf calculation to be more friendly, calc is the same but we use different variable to make it easier amongst the different code versions. - Signedness issue with one of the new var's (this is an issue mainly in apple but with the right -Wall it could effect us too). - optimize the initialization of the SB max variables. - Missing lock(s) when sending data and moving it to the outqueue. - If a mbuf alloc fails during moving to outqueue the reassembly of the old mbuf chain was incorrect. - some_taken becomes a counter in sctputil.c instead of a set to 1. - Fix a panic to be only under invarients and have a proper recovery in reading messages. - msg_flags needed to be set to the value collected not or'd. - More fixes for lock misses on the transfer of data to the sent_queue. Sometimes I wonder why any code ever works :-) - Fix the pad of the last mbuf routine, It was working improperly on non-4 byte aligned chunks which could cause memory overruns. Approved by: re@freebsd.org(gnn)