NetBSD Problem Report #10500

Received: (qmail 1386 invoked from network); 4 Jul 2000 01:29:13 -0000
Message-Id: <200007040128.e641SVs00703@nutcracker.s3.kth.se>
Date: Tue, 4 Jul 2000 03:28:31 +0200 (CEST)
From: lha@stacken.kth.se
Reply-To: lha@stacken.kth.se
To: gnats-bugs@gnats.netbsd.org
Subject: eon driver
X-Send-Pr-Version: 3.95

>Number:         10500
>Category:       kern
>Synopsis:       eon driver
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 04 01:30:00 +0000 2000
>Closed-Date:    
>Last-Modified:  Fri Jul 07 03:51:00 +0000 2000
>Originator:     Love
>Release:        NetBSD1.5_ALPHA
>Organization:
	Stacken
>Environment:
System: NetBSD nutcracker.s3.kth.se 1.5_ALPHA NetBSD 1.5_ALPHA (NUTCRACKER) #6: Sun Jul 2 14:25:53 CEST 2000 lha@nutcracker.s3.kth.se:/usr/src/sys/arch/i386/compile/NUTCRACKER i386


>Description:

	I think I have opend a PR about this before, but I couldn't
	find it again.

	The eon driver make the kernel panic with a:

		panic: free: duplicated free

	This happens the second time the dhclient is started
	without an argument (and with no other interfaces). Since the
	dhclient uses the first available interface.

>How-To-Repeat:

	ifconfig eon0 inet 0.0.0.0 netmask 0.0.0.0 \
                broadcast 255.255.255.255 up
	ifconfig eon0 down
	ifconfig eon0 inet 0.0.0.0 netmask 0.0.0.0 \
                broadcast 255.255.255.255 up

>Fix:
	Sorry, not a clue. I just removed it from my kernel
	configurationfile.
>Release-Note:
>Audit-Trail:

From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
To: lha@stacken.kth.se
Cc: gnats-bugs@gnats.netbsd.org, tech-net@netbsd.org
Subject: Re: kern/10500: eon driver 
Date: Tue, 04 Jul 2000 23:10:37 -0400

 executive summary: eon is horribly broken when given an address of
 0.0.0.0, requires some work, and, unless someone wants to spend a
 bunch of time rewriting it, we should just comment it out of the
 GENERIC configs on all ports.

 some analysis:

 eon implements RFC986, which appears to be a rough ISO equivalent of
 the IPv6 6to4 transition mechanism: using ipv4 as a link-layer
 protocol underlying ISO, with ipv4 addresses embedded in the addresses
 used by the upper layer protocol.

 It's doing something slightly screwy with routing, by attempting to
 keep a cached route around in the pseudo-device's softc.

 This is running afoul of some fairly squirrelly conventions within the
 main protocol-independant routing table code.

 background:

 a "struct route" is a parameterized reference to a route; a "struct
 rtentry" is the actual route.

 route entries are refcounted, with a twist: the reference from the
 routing table itself doesn't count as a reference!  (this is not
 documented anywhere I found).

 eon attempts to keep a cached copy of the route to the ipv4 default
 (all-zeros) address around which is used in certain cases (i haven't
 spent the time needed to understand exactly when).

 now, when you ifconfig eon0 to 0.0.0.0:
 	- the higher-level interface management code allocates an
 interface route to 0.0.0.0 for the ifaddr, set to refcount 1.
 	- rtrequest then calls into the interface-specific
 	  eonrtrequest routine to do interface-specific setup.
 	- eonrtrequest then looks up the route to 0.0.0.0, and finds
 	  the interface route to itself (!)  (which can't possibly
 	  work in practice..); this gets its refcount bumped up to 2
 	- on return from rtrequest(), rtinit() decrements the refcount
 	  of the route (back down to 1), since the reference from the
 	  routing table doesn't count.

 the second time around, the interface management code notices that the
 interface route already exists, and so it starts cleaning it up;
 rtrequest() is invoked, which then calls through to eonrtrequest,
 which releases the reference on that route (which drops it from 1 back
 down to 0), freeing the route.

 rtinit then frees it again:

 		if (rt->rt_refcnt <= 0) {
 			rt->rt_refcnt++;
 			rtfree(rt);
 		}

 Conclusions:

  - The pragmatic answer here is probably to declare EON as "broken, in
 need of work, but nobody really cares" and take it out of all the
 stock GENERIC configs on all supported architectures.

  - Handling of route reference counting is horribly underdocumented
 and confusing and just plain fragile.  If I were going to redesign
 things, one thing I would change would be to have ifaddrs explicitly
 hold references to route entries for both the ifa's address (pointing
 to loopback) and for the subnet/destination route associated with the
 ifa (pointing to the interface).

 						- Bill
State-Changed-From-To: open->analyzed 
State-Changed-By: sommerfeld 
State-Changed-When: Tue Jul 4 20:14:57 PDT 2000 
State-Changed-Why:  
analyzed to death. 

From: John Hawkinson <jhawk@MIT.EDU>
To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
Cc: gnats-bugs@gnats.netbsd.org, tech-net@netbsd.org
Subject: Re: kern/10500: eon driver
Date: Wed, 5 Jul 2000 01:18:15 -0400 (EDT)

 | executive summary: eon is horribly broken when given an address of
 | 0.0.0.0, requires some work, and, unless someone wants to spend a
 | bunch of time rewriting it, we should just comment it out of the
 | GENERIC configs on all ports.

 I was about to reply to this with a "We should never just comment
 things out of GENERIC, we should also adjust their BUGS sections in
 their manpage, especially on a release branch."

 However, there is no eon(4). This seems rather confusing given
 accepted practice], and should probably be corrected.

 But since there's no eon(4), and the eon interface is "documented"
 as "options EON" on options(4), could the BUGS section there be
 updated?

 Thanks.

 --jhawk

From: Bill Studenmund <wrstuden@zembu.com>
To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
Cc: lha@stacken.kth.se, gnats-bugs@gnats.netbsd.org, tech-net@netbsd.org
Subject: Re: kern/10500: eon driver 
Date: Thu, 6 Jul 2000 13:51:20 -0700 (PDT)

 On Tue, 4 Jul 2000, Bill Sommerfeld wrote:

 > executive summary: eon is horribly broken when given an address of
 > 0.0.0.0, requires some work, and, unless someone wants to spend a
 > bunch of time rewriting it, we should just comment it out of the
 > GENERIC configs on all ports.

 I think we should disable eon, but for another reason - it will take
 addresses for protocol families it doesn't support. netatalk will, by
 default, attach itself to all broadcast interfaces. Because of how eon is
 configured, netatalk will try to add an appletalk address to it, and to
 probe for other servers. The eon driver doesn't support that, and panics.

 So let's turn off eon by default. Just adding a "#" in front is fine.

 Take care,

 Bill




From: John Hawkinson <jhawk@MIT.EDU>
To: Bill Studenmund <wrstuden@zembu.com>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/10500: eon driver
Date: Thu, 6 Jul 2000 23:50:22 -0400 (EDT)

 [ dropped Love and tech-net ]

 | I think we should disable eon, but for another reason - it will take
 | addresses for protocol families it doesn't support. netatalk will, by
 | default, attach itself to all broadcast interfaces. Because of how eon is
 | configured, netatalk will try to add an appletalk address to it, and to
 | probe for other servers. The eon driver doesn't support that, and panics.
 | 
 | So let's turn off eon by default. Just adding a "#" in front is fine.

 One more for BUGS in options(4) or a PR, please?

 --jhawk
>Unformatted:

Home	PR Database Search