Re: IPv6 route mutex recursion (crash) and fix

From: B ($B?_at_L@C#:H(B)
Date: 09/23/04

  • Next message: Brian Fundakowski Feldman: "Re: IPv6 route mutex recursion (crash) and fix"
    Date: Fri, 24 Sep 2004 03:47:22 +0900
    To: Brian Fundakowski Feldman <green@FreeBSD.org>
    
    

    >>>>> 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.

    Thanks,

                                            JINMEI, Tatuya
                                            Communication Platform Lab.
                                            Corporate R&D Center, Toshiba Corp.
                                            jinmei@isl.rdc.toshiba.co.jp
    _______________________________________________
    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"


  • Next message: Brian Fundakowski Feldman: "Re: IPv6 route mutex recursion (crash) and fix"

    Relevant Pages

    • CARP broken in 6.1
      ... Assigning an IP address to a CARP interface leads to the new route table entry: ... Removing the entry manually seems to fix the issue. ...
      (freebsd-net)
    • Re: Differences between GNU and FreeBSD C library
      ... problems if the code you are porting relies on non-portable ... Even if you're not up to submitting a fix for the problem yet, ... a precise description of where FreeBSD departs from ... bug reports which also include a patch are very ...
      (comp.unix.bsd.freebsd.misc)
    • Re: Bug in #! processing - One More Time
      ... So I wrote up a quick fix and did ... > but I didn't want to commit it until I did more testing, ... > options on the shebang line the way FreeBSD does. ... > documented by perl (and other scripting languages), ...
      (freebsd-arch)
    • Re: /boot/loader Invalid Format
      ... if someone has freebsd release as you, let him upload it to a site, with ... then boot your computer with the fixit cd of freebsd ... (founded this trick out with a friend of mine who messed up her bootloader ... >> I've got a problem with my bootloader and i dont know how to fix it. ...
      (freebsd-hackers)
    • Re: freeBSD user
      ... If you are using DHCP, you need this entry in /etc/rc.conf: ... You can see the current default route ... If these settings are all correct, and you still don't have connectivity, the ... You have a firewall active on your FreeBSD system. ...
      (freebsd-questions)