CFR: routing table locking

From: Sam Leffler (sam_at_errno.com)
Date: 08/20/03

  • Next message: Sam Leffler: "CFR: bridge locking" 
    Date: Wed, 20 Aug 2003 09:14:19 -0700
To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org

    http://www.freebsd.org/~sam/rtentry.patch

    This is an extensive set of changes to lock routing table entries. There
    are some issues with these changes that will need to be resolved before
    committing the work. In particular the per-entry mutex is stored in the
    rtentry structure and this struct is visible to user applications like
    route(8). This must be fixed. For now I've #ifdef'd the mutex to be
    included only in the kernel. We'll either need to use an indirect
    reference to a mutex or, more likely, introduce an externalized version of
    struct rtentry to decouple kernel operation from user applications. It may
    be possible to jigger the code to make the lock in the entry be a leaf lock
    in which case we could use a mutex pool and a pointer to a mutex but I'm
    leaning more to decoupling the kernel from user apps as this has general
    benefits.

    These changes have been in use on 4 of my machines for several weeks. IPv6
    has only been lightly tested. In general I consider the code very lightly
    tested so don't be surprised if you encounter issues. Also, because of the
    wide visibility of the routing table in the system I may have missed some
    uses that need locking. There are a couple of LOR issues to be resolved.
    In particular I recall there is one with the ARP cache.

    Another issue is that these changes do not include multicast routing. That
    code has been changing recently so I left it alone. I'm not well setup to
    test multicast routing so if someone with an existing setup is interested
    in tacking this please let me know.

    Note there is one API change buried in these diffs. I dropped the last
    parameter to rtredirect that allowed callers to receive a reference to the
    associated entry. This was not used in the system and introduced issues
    for locking.

            Sam

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Sam Leffler: "CFR: bridge locking"

    Relevant Pages