Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Jul 2007 18:35:17 -0700
From:      Brian Somers <brians@ca.sophos.com>
To:        Brian Somers <brian@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/net if.c if_var.h src/sys/netinet in.c  in_var.h
Message-ID:  <20070706183517.512b6dab@conflict>
In-Reply-To: <200707070054.l670slr1007427@repoman.freebsd.org>
References:  <200707070054.l670slr1007427@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 7 Jul 2007 00:54:47 +0000 (UTC)
Brian Somers <brian@FreeBSD.org> wrote:

> brian       2007-07-07 00:54:47 UTC
> 
>   FreeBSD src repository
> 
>   Modified files:        (Branch: RELENG_6)
>     sys/net              if.c if_var.h 
>     sys/netinet          in.c in_var.h 
>   Log:
>   Fix a problem introduced in netinet/in.c 1.85.2.7 where
>   in_ifdetach() calls in_delmulti_ifp().
>   
>   The code now *really* deletes the elements in in_multihead
>   for the ifp that's going away (rather than just decrementing
>   the reference count).  Previously we were left with inm and
>   ifma structures containing bogus ifnet pointers after
>   destroying an interface that had more than one IP4 assignment
>   made to it in it's lifetime.
>   
>   I've also added a if_delmulti_ent() to make deleting known
>   ifma structures possible rather than depending on
>   if_findmulti() to end up finding the same thing.  It
>   will in fact always find the correct ifma *unless* the
>   passed sockaddr has a bogus sa_len of zero.
>   
>   Finally, when adding a multicast address, we no longer
>   increment the refcount (well, we do, but then we decrement
>   it again).  The refcount here is in fact bogus so hopefully
>   readers will see that now.
>   
>   This code is going directly into -stable as it has been
>   rewritten in -current and those changes are deemed too
>   intrusive for -stable consumption right now.
>   
>   Reviewed by:    bms
>   
>   Revision    Changes    Path
>   1.234.2.20  +32 -11    src/sys/net/if.c
>   1.98.2.8    +1 -0      src/sys/net/if_var.h
>   1.85.2.9    +28 -22    src/sys/netinet/in.c
>   1.53.2.5    +0 -1      src/sys/netinet/in_var.h

For those interested, here's how the breakage was demonstrated.
The script is a little roundabout so that it mimics the
ifconfig calls from a set of unit tests here.  The panic
can be expected after up to 20 iterations.

#! /bin/sh

[ $# -eq 1 ] && max=$1 || max=0
n=0
while [ $max -eq 0 -o $n -lt $max ]
do
    n=$(($n + 1))
    printf "\r$n"

    for f in 1 2 3 4 5
    do
        ifconfig lo1$f >/dev/null 2>&1 || ifconfig lo1$f create
        ifconfig lo1$f 127.0.$f.$f netmask 0xffffffff
    done

    ifconfig lo13 127.0.3.3 delete
    ifconfig lo13 127.0.3.3 netmask 0xffffffff

    for f in 1 2 3 4 5
    do
        ifconfig lo1$f destroy
    done

    for f in 1 2 3
    do
        ifconfig lo$f >/dev/null 2>&1 || ifconfig lo$f create
    done

    for f in 1 2 3
    do
        ifconfig lo$f 127.$f.$f.$f netmask 0xffffffff
    done

    ifconfig lo3 127.3.3.3 delete
    ifconfig lo3 127.3.3.3 netmask 0xffffffff

    ifconfig lo2 127.2.2.3 netmask 0xffffffff
    ifconfig lo2 127.2.2.3 delete
    ifconfig lo2 127.2.2.2 netmask 0xffffffff

    for f in 1 2 3
    do
        ifconfig lo$f destroy
    done
done
[ $n -eq 0 ] || echo

-- 
Brian Somers                                       Tel: +1 604 484 6434
                                                   Mob: +1 604 315 1343
Sophos - security and control                      Web:  www.sophos.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070706183517.512b6dab>