From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 15:05:51 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.bikeshed.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id F347016A4CE for ; Tue, 9 Dec 2003 15:05:50 -0800 (PST) Received: from green.bikeshed.org (green@localhost [127.0.0.1]) by green.bikeshed.org (8.12.10/8.12.9) with ESMTP id hB9N5nnU033894 for ; Tue, 9 Dec 2003 18:05:49 -0500 (EST) (envelope-from green@green.bikeshed.org) Received: from localhost (green@localhost)hB9N5mpI033891 for ; Tue, 9 Dec 2003 18:05:48 -0500 (EST) Message-Id: <200312092305.hB9N5mpI033891@green.bikeshed.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: current@FreeBSD.org From: Brian Fundakowski Feldman Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Dec 2003 18:05:48 -0500 Sender: green@green.bikeshed.org Subject: yet more current routing bugs, as noticed by WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2003 23:05:51 -0000 The copy of isc-dhcpd running causes this bug to occur with the routing table in an unknown state with a call to sendto(0.0.0.0). All I really know is that the bug is the lock for the rtentry being recursed on because it has no rt_gwroute, yet has flags set to exactly RTF_UP|RTF_GATEWAY, and gets returned again by rtalloc1(). You can find it in rt_check() easily enough if you follow the RTF_UP, RTF_GATEWAY path downward. panic(c0663eb9,c0669491,b6,c0669491,50c) at panic+0xd5 witness_lock(c1878264,8,c0669491,50c,c1878200) at witness_lock+0x3b3 _mtx_lock_flags(c1878264,0,c0669488,50c,32) at _mtx_lock_flags+0xba rt_check(c634ba20,c634ba68,c1650650,c04e5440,c1870000) at rt_check+0x19a ether_output(c1626000,c0e43700,c1650650,c1878200,c051642a) at ether_output+0x60 ip_output(c0e43700,0,0,20,0) at ip_output+0xdb1 udp_output(c16a84ec,c0e43700,c0df9820,0,c15c3780) at udp_output+0x408 udp_send(c16a4690,0,c0e43700,c0df9820,0) at udp_send+0xb7 sosend(c16a4690,c0df9820,c634bc4c,c0e43700,0) at sosend+0x44d kern_sendit(c15c3780,5,c634bcc4,0,0) at kern_sendit+0x17c sendit(c15c3780,5,c634bcc4,0,806a03c) at sendit+0x16e sendto(c15c3780,c634bd14,c0677f0f,3ee,6) at sendto+0x5b syscall(bfbf002f,2f,bfbf002f,bfbfeba1,bfbfed60) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (133, FreeBSD ELF32, sendto), eip = 0x280f468f, esp = 0xbfbfe6fc, ebp = 0xbfbfe748 --- Also of note is that the rt_setgate() function also in net/route.c includes a clause to return EDQUOT if something similar occurs. As it is, I have no idea of that one can occur, or much else in the matter. Anyone that might know anything about this I'd appreciate help from. Thanks! -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\