From owner-freebsd-current Mon Dec 15 07:31:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA06175 for current-outgoing; Mon, 15 Dec 1997 07:31:43 -0800 (PST) (envelope-from owner-freebsd-current) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA05585 for ; Mon, 15 Dec 1997 07:26:26 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.5) id KAA08128; Mon, 15 Dec 1997 10:24:42 -0500 (EST) Date: Mon, 15 Dec 1997 10:24:42 -0500 (EST) From: Garrett Wollman Message-Id: <199712151524.KAA08128@khavrinen.lcs.mit.edu> To: pb@fasterix.freenix.org (Pierre Beyssac) Cc: wollman@khavrinen.lcs.mit.edu (Garrett Wollman), tlambert@primenet.com (Terry Lambert), totii@est.is (?or?ur Ivarsson), freebsd-current@FreeBSD.ORG Subject: Re: panics when stopping pppd In-Reply-To: <19971215020638.WG24374@@> References: <3492A8DE.27B270DB@est.is> <199712132150.OAA03369@usr06.primenet.com> <19971214024134.PL39369@@> <199712141929.OAA04089@khavrinen.lcs.mit.edu> <19971215020638.WG24374@@> Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < Garrett Wollman writes: >> Another thing that might be worth taking a look at... rn_walktree() is >> supposed to be written such that it is resilient to deletes happening >> in its callback. But, I'm not sure if it can deal with the case of >> multiple records being deleted at once, particularly if one of those >> records turns out to be the place it was going next. > That's apparently a good idea since the fix I've made from that > seems to work :-) This seems to confirm my theory. Here's what I think is happening: 1) An interface is downed. All of its non-static routes get deleted automatically. 2) One of those interface routes was a cloning route. rtrequest() notices this, and deletes all of its children. 3) Oops, a pointer to one of those children was held by rn_walktree() as the next node to examine... blam! I think the right fix is to disable (2) while this is happening, since the deletion code in (1) will end up deleting those same routes. It looks like this might be as simple as turning off RTF_PRCLONING in (1) before calling rtrequest(). I have what I think is the right idea for cleaning this mess up, but have not had time to implement the solution. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick