Date: Wed, 18 Jan 2006 23:36:49 +0000 (UTC) From: Ed Maste <emaste@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern subr_witness.c src/sys/netinet igmp.c in.c in_var.h ip_input.c ip_output.c src/sys/netinet6 in6_var.h mld6.c Message-ID: <200601182336.k0INanhb004198@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
emaste 2006-01-18 23:36:49 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_5)
sys/kern subr_witness.c
sys/netinet igmp.c in.c in_var.h ip_input.c
ip_output.c
sys/netinet6 in6_var.h mld6.c
Log:
Merge IP multicast address list locking from HEAD to RELENG_5, with a
few changes to preserve ABI compatibility.
subr_witness.c:1.196:
Add in_multi_mtx, igmp_mtx, and if_addr_mtx lock order to hard-coded
lock order in WITNESS, in that order.
in_var.h:1.54 in6_var.h:1.23 mld6.c:1.22:
Modify network protocol consumers of the ifnet multicast address lists
to lock if_addr_mtx.
igmp.c:1.49 in.c:1.86: in_var.h:1.55 ip_input.c:1.303 ip_output.c:1.243:
Introduce in_multi_mtx, which will protect IPv4-layer multicast address
lists, as well as accessor macros. For now, this is a recursive mutex
due code sequences where IPv4 multicast calls into IGMP calls into
ip_output(), which then tests for a multicast forwarding case.
For support macros in in_var.h to check multicast address lists, assert
that in_multi_mtx is held.
Acquire in_multi_mtx around iteration over the IPv4 multicast address
lists, such as in ip_input() and ip_output().
Acquire in_multi_mtx when manipulating the IPv4 layer multicast
addresses, as well as over the manipulation of ifnet multicast address
lists in order to keep the two layers in sync.
Lock down accesses to IPv4 multicast addresses in IGMP, or assert the
lock when performing IGMP join/leave events.
Eliminate spl's associated with IPv4 multicast addresses, portions of
IGMP that weren't previously expunged by IGMP locking.
in.c:1.89 in.c:1.90:
Acquire Giant conditionally in in_addmulti() and in_delmulti() based on
whether the interface being accessed is IFF_NEEDSGIANT or not. This
avoids lock order reversals when calling into the interface ioctl
handler, which could potentially lead to deadlock.
The long term solution is to eliminate non-MPSAFE network drivers.
Discussed with: jhb
Unlock Giant symmetrically with respect to lock acquire order as that's
generally nicer.
Spotted by: johan
ip_output.c:1.244:
Add helper function ip_findmoptions(), which accepts an inpcb, and attempts
to atomically return either an existing set of IP multicast options for the
PCB, or a newlly allocated set with default values. The inpcb is returned
locked. This function may sleep.
Call ip_moptions() to acquire a reference to a PCB's socket options, and
perform the update of the options while holding the PCB lock. Release the
lock before returning.
Remove garbage collection of multicast options when values return to the
default, as this complicates locking substantially. Most applications
allocate a socket either to be multicast, or not, and don't tend to keep
around sockets that have previously been used for multicast, then used for
unicast.
This closes a number of race conditions involving multiple threads or
processes modifying the IP multicast state of a socket simultaenously.
Approved by: rwatson (mentor)
Revision Changes Path
1.178.2.9 +7 -0 src/sys/kern/subr_witness.c
1.46.2.2 +12 -8 src/sys/netinet/igmp.c
1.77.2.7 +27 -10 src/sys/netinet/in.c
1.51.2.2 +16 -0 src/sys/netinet/in_var.h
1.283.2.15 +2 -0 src/sys/netinet/ip_input.c
1.225.2.13 +61 -33 src/sys/netinet/ip_output.c
1.19.2.3 +2 -0 src/sys/netinet6/in6_var.h
1.17.2.3 +2 -0 src/sys/netinet6/mld6.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601182336.k0INanhb004198>