Re: IPv6 route mutex recursion (crash) and fix
From: Brian Fundakowski Feldman (green_at_FreeBSD.org)
Date: 09/23/04
- Previous message: B: "Re: IPv6 route mutex recursion (crash) and fix"
- In reply to: B: "Re: IPv6 route mutex recursion (crash) and fix"
- Next in thread: B: "Re: IPv6 route mutex recursion (crash) and fix"
- Reply: B: "Re: IPv6 route mutex recursion (crash) and fix"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 23 Sep 2004 14:58:41 -0400 To: "JINMEI Tatuya / ?$B?@L@C#:H" <jinmei@isl.rdc.toshiba.co.jp>
On Fri, Sep 24, 2004 at 03:47:22AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Tue, 21 Sep 2004 22:09:57 -0400,
> >>>>> Brian Fundakowski Feldman <green@FreeBSD.org> said:
>
> > I've already made noise about this before, so I'll be brief. I plan on
> > committing the following fix that prevents the routing code from being
> > recursed upon such that RTM_RESOLVE causes the embryonic new route to
> > be looked up again. I realize that probably no one will bother trying
> > to see this bug in action, but all you need to do is send some UDP6 to
> > ff02::1%<if> as a user, with INVARIANTS turned on.
>
> > Are there any objections? It would be nice to have this in 5-STABLE,
> > in case anyone actually wants to have IPv6.
>
> The patch itself looks okay with the rationale you explained in a
> follow-up message. However, I have some related comments.
>
> As commented in nd6_rtrequest(), the purpose for checking
> nd6_is_addr_neighbor() in this function was to avoid creating a
> neighbor cache for the destination of some special host-routes. For
> FreeBSD, this can happen with the route which has the RTF_PRCLONING
> flag. However, since recent versions of FreeBSD (seems to) have got
> rid of this flag, we might even remove the check in nd6_rtrequest()
> altogether. (Then we'd not need to modify nd6_is_addr_neighbor().)
>
> But removing the check may be too radical and may have unexpected
> side-effect. Also, it'd be nice if we could keep the difference
> between the FreeBSD repository code and the KAME snap code as small as
> possible, in terms of future merge efforts. In this sense, removing
> the nd6_is_addr_neighbor() check from nd6_rtrequest() might be a
> suboptimal solution.
>
> So, as a result, I tend to think the proposed patch is a reasonable
> fix to the problem. But please add the rationale as comments, since
> the background intent is a bit vague as shown by the question from
> George.
Thank you for your review. As you certainly are more knowledgable in KAME
code than I am, would you mind redoing this so that the style is more
closely matched; then I could take the change from the KAME repository?
-- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
- Previous message: B: "Re: IPv6 route mutex recursion (crash) and fix"
- In reply to: B: "Re: IPv6 route mutex recursion (crash) and fix"
- Next in thread: B: "Re: IPv6 route mutex recursion (crash) and fix"
- Reply: B: "Re: IPv6 route mutex recursion (crash) and fix"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
