Date: Mon, 15 Dec 1997 10:24:42 -0500 (EST) From: Garrett Wollman <wollman@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 Message-ID: <199712151524.KAA08128@khavrinen.lcs.mit.edu> 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@@>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Mon, 15 Dec 1997 02:06:38 +0100, pb@fasterix.freenix.org (Pierre Beyssac) said: > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712151524.KAA08128>