src/sys/netinet, branch release/6.2.0 FreeBSD source tree Merge ip_output.c:1.242.2.17, ip_var.h:1.95.2.1, tcp_usrreq.c:1.124.2.4 2006-11-28T23:19:18+00:00 Robert Watson rwatson@FreeBSD.org 2006-11-28T23:19:18+00:00 f64496d070e622aa3a0ff03f2029badd3b96a1c3 from RELENG_6 to RELENG_6_2: Reformulate ip_ctloutput() and tcp_ctloutput() to work around the fact that so_pcb can be invalidated at any time due to an untimely reset. Move the body of ip_ctloutput() to ip_ctloutput_pcbinfo(), which accepts a pcbinfo argument, and wrap it with ip_ctloutput(), which passes a NULL. Modify tcp_ctloutput() to directly invoke ip_ctloutput_pcbinfo() and pass tcbinfo. Hold the pcbinfo lock when dereferencing so_pcb and acquiring the inpcb lock in order to prevent the inpcb from being freed; the pcbinfo lock is then immediately dropped. This is required as TCP may free the inppcb and invalidate so_pcb due to a reset at any time in the RELENG_6 network stack, which otherwise leads to a panic. This panic might be frequently seen on highly loaded IRC and Samba servers, which have long-lasting TCP connections, query socket options frequently, and see a significant number of reset connections. This change has been merged directly to RELENG_6 as the problem does not exist in HEAD, where the invariants for so_pcb are much stronger; the architectural changes in HEAD avoid the need to acquire a global lock in the socket option path. This change will be merged to RELENG_6_2. PR: 102412, 104765 Reviewed by: Diane Bruce <db at db.net> Tested by: Daniel Austin <daniel at kewlio dot net>, Kai Gallasch <gallasch at free dot de> Approved by: re (kensmith) 
from RELENG_6 to RELENG_6_2:

  Reformulate ip_ctloutput() and tcp_ctloutput() to work around the fact
  that so_pcb can be invalidated at any time due to an untimely reset.
  Move the body of ip_ctloutput() to ip_ctloutput_pcbinfo(), which
  accepts a pcbinfo argument, and wrap it with ip_ctloutput(), which
  passes a NULL.  Modify tcp_ctloutput() to directly invoke
  ip_ctloutput_pcbinfo() and pass tcbinfo.  Hold the pcbinfo lock when
  dereferencing so_pcb and acquiring the inpcb lock in order to prevent
  the inpcb from being freed; the pcbinfo lock is then immediately
  dropped.  This is required as TCP may free the inppcb and invalidate
  so_pcb due to a reset at any time in the RELENG_6 network stack, which
  otherwise leads to a panic.

  This panic might be frequently seen on highly loaded IRC and Samba
  servers, which have long-lasting TCP connections, query socket options
  frequently, and see a significant number of reset connections.

  This change has been merged directly to RELENG_6 as the problem does
  not exist in HEAD, where the invariants for so_pcb are much stronger;
  the architectural changes in HEAD avoid the need to acquire a global
  lock in the socket option path.  This change will be merged to
  RELENG_6_2.

  PR:             102412, 104765
  Reviewed by:    Diane Bruce <db at db.net>
  Tested by:      Daniel Austin <daniel at kewlio dot net>,
                  Kai Gallasch <gallasch at free dot de>

Approved by:	re (kensmith)
Reduce the size of a number of race windows in the TCP socket options 2006-10-24T13:23:03+00:00 Robert Watson rwatson@FreeBSD.org 2006-10-24T13:23:03+00:00 fca84b2e517c86399f68c39cf107d7ca6da46dfe processing code: a RST may arrive during a socket option call, causing the PCB to be freed, leading to an invalid pointer dereference. When the kernel blocks in a socket option copyin or memory allocation (such as during heavy paging), the race window is greatly widened. This change re-validates the PCB pointer after returning from the copy/alloc operation. This does not eliminate the problem, but does narrow the window significantly (to the point where it may not be observed at all). The proper fix is in 7.x, which significantly re-works the socket and PCB code so that PCB's are not ripped out from under sockets on reset. However, those changes are not appropriate for an MFC during a release cycle. As a result, this is not an MFC, but new code crafted for 6.x. PR: kern/102412 Reported by: Daniel Austin <daniel at kewlio dot net> Tested by: Diane Bruce <db at db dot net> Reviewed by: Diane Bruce <db at db dot net> Approved by: re (kensmith) 
processing code: a RST may arrive during a socket option call, causing
the PCB to be freed, leading to an invalid pointer dereference.  When
the kernel blocks in a socket option copyin or memory allocation (such
as during heavy paging), the race window is greatly widened.  This
change re-validates the PCB pointer after returning from the copy/alloc
operation.  This does not eliminate the problem, but does narrow the
window significantly (to the point where it may not be observed at all).

The proper fix is in 7.x, which significantly re-works the socket and
PCB code so that PCB's are not ripped out from under sockets on reset.
However, those changes are not appropriate for an MFC during a release
cycle.  As a result, this is not an MFC, but new code crafted for 6.x.

PR:			kern/102412
Reported by:		Daniel Austin <daniel at kewlio dot net>
Tested by:		Diane Bruce <db at db dot net>
Reviewed by:		Diane Bruce <db at db dot net>
Approved by:		re (kensmith)
MFC: 1.44 src/sys/netinet/ip_carp.c, 1.148 src/sys/netinet/ip_fw2.c 2006-10-10T18:39:38+00:00 Bjoern A. Zeeb bz@FreeBSD.org 2006-10-10T18:39:38+00:00 a49db1f9bc604c4649a5e6031415055e890a3738 > Set scope on MC address so IPv6 carp advertisement will not get dropped > in ip6_output. In case this fails handle the error directly and log it. > In addition permit CARP over v6 in ip_fw2. PR: kern/98622 Similar patch by: suz Discussed with: glebius [1] Tested by: Paul.Dekkers surfnet.nl, Philippe.Pegon crc.u-strasbg.fr Approved by: re (hrs) 
> Set scope on MC address so IPv6 carp advertisement will not get dropped
> in ip6_output. In case this fails  handle the error directly and log it.
> In addition permit CARP over v6 in ip_fw2.

PR:			kern/98622
Similar patch by:	suz
Discussed with:		glebius [1]
Tested by:		Paul.Dekkers surfnet.nl, Philippe.Pegon crc.u-strasbg.fr
Approved by:		re (hrs)
MFC: Fix the IPv4 multicast routing detach path. On interface detach whilst 2006-10-07T10:45:05+00:00 Bruce M Simpson bms@FreeBSD.org 2006-10-07T10:45:05+00:00 7ad4e13f5f07bc8ff969d36ef9a142c050e828b8 the MROUTER is running, the system would panic as described in the PR. The fix in the PR is a good start, however, the other state associated with the multicast forwarding cache has to be freed in order to avoid leaking memory and other possible panics. More care and attention is needed in this area. PR: kern/82882 Approved by: re (rwatson) Revs: 1.119 src/sys/netinet/ip_mroute.c 
the MROUTER is running, the system would panic as described in the PR.

The fix in the PR is a good start, however, the other state associated
with the multicast forwarding cache has to be freed in order to avoid
leaking memory and other possible panics.

More care and attention is needed in this area.

PR:		kern/82882
Approved by:	re (rwatson)
Revs:		1.119 src/sys/netinet/ip_mroute.c
MFC: The IPv4 code should clean up multicast group state when an interface 2006-10-07T10:43:40+00:00 Bruce M Simpson bms@FreeBSD.org 2006-10-07T10:43:40+00:00 396009a3b272e77a43877ea0979d9e8edcb49662 goes away. Without this change, it leaks in_multi (and often ether_multi state) if many clonable interfaces are created and destroyed in quick succession. The concept of this fix is borrowed from KAME. Detailed information about this behaviour, as well as test cases, are available in the PR. PR: kern/78227 Approved by: re (rwatson) Revs: 1.94 src/sys/netinet/in.c Revs: 1.59 src/sys/netinet/in_var.h 
goes away. Without this change, it leaks in_multi (and often ether_multi
state) if many clonable interfaces are created and destroyed in quick
succession.

The concept of this fix is borrowed from KAME. Detailed information about
this behaviour, as well as test cases, are available in the PR.

PR:		kern/78227
Approved by:	re (rwatson)
Revs:		1.94 src/sys/netinet/in.c
Revs:		1.59 src/sys/netinet/in_var.h
MFC: 2006-10-06T20:26:06+00:00 Andre Oppermann andre@FreeBSD.org 2006-10-06T20:26:06+00:00 2ff7ea5796544cbca16bd5dcef3d6349a30a23bb - Fix the socket option IP_ONESBCAST by giving it its own case in ip_output() and skip over the normal IP processing. - Add a supporting function ifa_ifwithbroadaddr() to verify and validate the supplied subnet broadcast address. - Check inp_flags instead of inp_vflag for INP_ONESBCAST flag. PR: kern/99558 Approved by: re (kensmith) 
 - Fix the socket option IP_ONESBCAST by giving it its own case in ip_output()
   and skip over the normal IP processing.
 - Add a supporting function ifa_ifwithbroadaddr() to verify and validate the
   supplied subnet broadcast address.
 - Check inp_flags instead of inp_vflag for INP_ONESBCAST flag.

PR:		kern/99558
Approved by:	re (kensmith)
MFC revs 1.263, 1.264: Limit the number of TIME_WAIT sockets we allocate 2006-10-01T05:33:50+00:00 Mike Silbersack silby@FreeBSD.org 2006-10-01T05:33:50+00:00 193c27268dc90ce9b19962a3356eba108a2e208c so that the ephemeral port range can not be exhausted by sockets in TIME_WAIT. Approved by: re (kensmith) 
so that the ephemeral port range can not be exhausted by sockets in
TIME_WAIT.

Approved by:	re (kensmith)
MFC udp_usrreq.c:1.180 and tcp_usrreq.c:1.128 : 2006-09-27T09:24:44+00:00 Maxime Henrion mux@FreeBSD.org 2006-09-27T09:24:44+00:00 9d7c167dbe946df8317fc5745f09f66ec001e91a Fix a bunch of SYSCTL_INT() that should have been SYSCTL_ULONG() to match the type of the variable they are exporting. Spotted by: Thomas Hurst <tom@hur.st> Approved by: re@ (rwatson) Forgotten by: mux 
  Fix a bunch of SYSCTL_INT() that should have been SYSCTL_ULONG() to
  match the type of the variable they are exporting.

  Spotted by:     Thomas Hurst <tom@hur.st>

Approved by:	re@ (rwatson)
Forgotten by:	mux
Back out rev 1.242.2.13 as it introduces a potentially expensive hash lookup 2006-09-26T18:28:38+00:00 Bruce M Simpson bms@FreeBSD.org 2006-09-26T18:28:38+00:00 44567da0f42810bb7f34492d94ab4c7888b1f291 to the ip output path. A better way needs to be found to resolve this. Approved by: re@ 
to the ip output path. A better way needs to be found to resolve this.

Approved by:	re@
MFC: Account for output IP datagrams on the ifaddr where they will 2006-09-25T13:02:58+00:00 Bruce M Simpson bms@FreeBSD.org 2006-09-25T13:02:58+00:00 ee66669144586b6471680344145fa94c805dc298 be sent from, not the first ifaddr on the ifp. PR: kern/72936 Submitted by: alfred Reviewed by: andre Approved by: re@ 
be sent from, not the first ifaddr on the ifp.

PR:		kern/72936
Submitted by:	alfred
Reviewed by:	andre
Approved by:	re@