From owner-svn-src-all@FreeBSD.ORG Fri Jun 6 22:14:26 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5458CE9; Fri, 6 Jun 2014 22:14:26 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34635257C; Fri, 6 Jun 2014 22:14:26 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s56MEQWx088187; Fri, 6 Jun 2014 22:14:26 GMT (envelope-from asomers@svn.freebsd.org) Received: (from asomers@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s56MEPDl088184; Fri, 6 Jun 2014 22:14:25 GMT (envelope-from asomers@svn.freebsd.org) Message-Id: <201406062214.s56MEPDl088184@svn.freebsd.org> From: Alan Somers Date: Fri, 6 Jun 2014 22:14:25 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org Subject: svn commit: r267195 - in stable/10: sys/netinet tests/sys/netinet X-SVN-Group: stable-10 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 22:14:26 -0000 Author: asomers Date: Fri Jun 6 22:14:25 2014 New Revision: 267195 URL: http://svnweb.freebsd.org/changeset/base/267195 Log: MFC changes related to PR kern/189089. Unlike CURRENT, stable/10 does not panic when you attempt to remove the IP address. But it still fails to remove the address. MFC r265094 Add regression test for PR kern/189088. MFC r265092 Fix a panic when removing an IP address from an interface, if the same address exists on another interface. The panic was introduced by change 264887, which changed the fibnum parameter in the call to rtalloc1_fib() in ifa_switch_loopback_route() from RT_DEFAULT_FIB to RT_ALL_FIBS. The solution is to use the interface fib in that call. For the majority of users, that will be equivalent to the legacy behavior. Modified: stable/10/sys/netinet/in.c stable/10/tests/sys/netinet/fibs_test.sh Directory Properties: stable/10/ (props changed) Modified: stable/10/sys/netinet/in.c ============================================================================== --- stable/10/sys/netinet/in.c Fri Jun 6 21:58:27 2014 (r267194) +++ stable/10/sys/netinet/in.c Fri Jun 6 22:14:25 2014 (r267195) @@ -987,11 +987,9 @@ in_scrubprefix(struct in_ifaddr *target, { struct in_ifaddr *ia; struct in_addr prefix, mask, p, m; - int error = 0, fibnum; + int error = 0; struct sockaddr_in prefix0, mask0; - fibnum = rt_add_addr_allfibs ? RT_ALL_FIBS : target->ia_ifp->if_fib; - /* * Remove the loopback route to the interface address. * The "useloopback" setting is not consulted because if the @@ -1046,6 +1044,10 @@ in_scrubprefix(struct in_ifaddr *target, } if ((target->ia_flags & IFA_ROUTE) == 0) { + int fibnum; + + fibnum = rt_add_addr_allfibs ? RT_ALL_FIBS : + target->ia_ifp->if_fib; rt_addrmsg(RTM_DELETE, &target->ia_ifa, fibnum); return (0); } Modified: stable/10/tests/sys/netinet/fibs_test.sh ============================================================================== --- stable/10/tests/sys/netinet/fibs_test.sh Fri Jun 6 21:58:27 2014 (r267194) +++ stable/10/tests/sys/netinet/fibs_test.sh Fri Jun 6 22:14:25 2014 (r267195) @@ -213,6 +213,98 @@ default_route_with_multiple_fibs_on_same } +# Regression test for PR kern/189089 +# Create two tap interfaces and assign them both the same IP address but with +# different netmasks, and both on the default FIB. Then remove one's IP +# address. Hopefully the machine won't panic. +atf_test_case same_ip_multiple_ifaces_fib0 cleanup +same_ip_multiple_ifaces_fib0_head() +{ + atf_set "descr" "Can remove an IP alias from an interface when the same IP is also assigned to another interface." + atf_set "require.user" "root" + atf_set "require.config" "fibs" +} +same_ip_multiple_ifaces_fib0_body() +{ + ADDR="192.0.2.2" + MASK0="24" + MASK1="32" + + # Unlike most of the tests in this file, this is applicable regardless + # of net.add_addr_allfibs + + # Setup the interfaces, then remove one alias. It should not panic. + setup_tap 0 ${ADDR} ${MASK0} + TAP0=${TAP} + setup_tap 0 ${ADDR} ${MASK1} + TAP1=${TAP} + ifconfig ${TAP1} -alias ${ADDR} + + # Do it again, in the opposite order. It should not panic. + setup_tap 0 ${ADDR} ${MASK0} + TAP0=${TAP} + setup_tap 0 ${ADDR} ${MASK1} + TAP1=${TAP} + ifconfig ${TAP0} -alias ${ADDR} +} +same_ip_multiple_ifaces_fib0_cleanup() +{ + cleanup_tap +} + +# Regression test for PR kern/189088 +# Test that removing an IP address works even if the same IP is assigned to a +# different interface, on a different FIB. Tests the same code that whose +# panic was regressed by same_ip_multiple_ifaces_fib0. +# Create two tap interfaces and assign them both the same IP address but with +# different netmasks, and on different FIBs. Then remove one's IP +# address. Hopefully the machine won't panic. Also, the IP's hostroute should +# dissappear from the correct fib. +atf_test_case same_ip_multiple_ifaces cleanup +same_ip_multiple_ifaces_head() +{ + atf_set "descr" "Can remove an IP alias from an interface when the same IP is also assigned to another interface, on non-default FIBs." + atf_set "require.user" "root" + atf_set "require.config" "fibs" +} +same_ip_multiple_ifaces_body() +{ + atf_expect_fail "kern/189088 Assigning the same IP to multiple interfaces in different FIBs creates a host route for only one" + ADDR="192.0.2.2" + MASK0="24" + MASK1="32" + + # Unlike most of the tests in this file, this is applicable regardless + # of net.add_addr_allfibs + get_fibs 2 + + # Setup the interfaces, then remove one alias. It should not panic. + setup_tap ${FIB0} ${ADDR} ${MASK0} + TAP0=${TAP} + setup_tap ${FIB1} ${ADDR} ${MASK1} + TAP1=${TAP} + ifconfig ${TAP1} -alias ${ADDR} + atf_check -o not-match:"^${ADDR}[[:space:]]" \ + setfib ${FIB1} netstat -rn -f inet + + # Do it again, in the opposite order. It should not panic. + setup_tap ${FIB0} ${ADDR} ${MASK0} + TAP0=${TAP} + setup_tap ${FIB1} ${ADDR} ${MASK1} + TAP1=${TAP} + ifconfig ${TAP0} -alias ${ADDR} + atf_check -o not-match:"^${ADDR}[[:space:]]" \ + setfib ${FIB0} netstat -rn -f inet +} +same_ip_multiple_ifaces_cleanup() +{ + # Due to PR kern/189088, we must destroy the interfaces in LIFO order + # in order for the routes to be correctly cleaned up. + for TAPD in `tail -r "tap_devices_to_cleanup"`; do + ifconfig ${TAPD} destroy + done +} + # Regression test for kern/187550 atf_test_case subnet_route_with_multiple_fibs_on_same_subnet cleanup subnet_route_with_multiple_fibs_on_same_subnet_head() @@ -322,6 +414,8 @@ atf_init_test_cases() atf_add_test_case arpresolve_checks_interface_fib atf_add_test_case loopback_and_network_routes_on_nondefault_fib atf_add_test_case default_route_with_multiple_fibs_on_same_subnet + atf_add_test_case same_ip_multiple_ifaces_fib0 + atf_add_test_case same_ip_multiple_ifaces atf_add_test_case subnet_route_with_multiple_fibs_on_same_subnet atf_add_test_case udp_dontroute }