Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Mar 2007 20:30:51 GMT
From:      "Devon H. O'Dell"<devon.odell@coyotepoint.com>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   kern/110284: [PATCH] Invalid Assumption in SIOCSIFADDR in ether_ioctl()
Message-ID:  <200703132030.l2DKUpc6069159@www.freebsd.org>
Resent-Message-ID: <200703132040.l2DKe5Sv020983@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         110284
>Category:       kern
>Synopsis:       [PATCH] Invalid Assumption in SIOCSIFADDR in ether_ioctl()
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 13 20:40:05 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     Devon H. O'Dell
>Release:        6.2-STABLE
>Organization:
Coyote Point Systems, Inc.
>Environment:
FreeBSD dho.coyotepoint.com 6.2-STABLE FreeBSD 6.2-STABLE #3: Fri Feb 23 16:45:30 EST 2007     dho@dho.coyotepoint.com:/usr/obj/usr/src/sys/SMP  i386
>Description:
Many NICs simply offload ioctls for SIOCSIFADDR to ether_ioctl(). When in
ether_ioctl(), we call the interface's if_init() routine. This is good 
when the interface is down and we haven't assigned an IP address yet. 
However, this routine is also called when aliases are added to the 
interface.

Calling if_init() at this point is undesirable because the chip is 
lready running and doesn't need to be initialized again. Additionally, 
for some chips (em(4) and vr(4) in my observations) the number of chip 
resets and the time required to autonegotiate is significant enough to 
cause the NIC to go OTL for a significant period of time (>15 seconds).

The attached patch only calls if_init() if the driver's if_flags field 
*DOES NOT* have the IFF_RUNNING bit set.

The gratuitous ARP (which is sent, if I understand correctly, because of
the succeeding arp_ifinit() call) should still be sent in either case.
>How-To-Repeat:
I'm not sure whether this is visible on all em(4) or vr(4) chips. To
visualize the problem, open two terminal sessions. In one, ping a machine
on the same network. On another, add an interface alias. Some number of
packets should never reach their destination.
>Fix:
A patch is available at http://databits.net/~dho/if_ethersubr.patch

I would have attached it, but the form doesn't like the Content-type
of my if_ethersubr.patch :(
>Release-Note:
>Audit-Trail:
>Unformatted:



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