CFR: fastforwarding locking

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

  • Next message: Sam Leffler: "CFR: fast ipsec locking"
    Date: Wed, 20 Aug 2003 08:43:02 -0700
    To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org
    
    

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

    These lock the fast forwarding hash table with a lock per hash bucket.
    There is one known issue with these changes: a LOR with the bridge code
    caused by holding a lock across the call to forward the packet. Also, some
    statistics are not consistently updated.

    Beware of overlap with routing table locking changes.

            Sam

    _______________________________________________
    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: Sam Leffler: "CFR: fast ipsec locking"

    Relevant Pages

    • CFR: fastforwarding locking
      ... These lock the fast forwarding hash table with a lock per hash bucket. ... There is one known issue with these changes: a LOR with the bridge code ...
      (freebsd-arch)
    • Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet (traces)
      ... R/W lock and mutexes that don't have any lock order with ... the pfil R/W lock at all. ... Note that the first LOR features a recursive pickup of the pfil R/W lock. ...
      (freebsd-stable)
    • Re: LOR #193
      ... The consequence of the LOR is lock up. ... not built against patched kernel (patch changes the kernel binary ...
      (freebsd-stable)
    • Re: LOR in Jan16 -CUR, ACPI related possibly
      ... On Sunday 16 January 2005 04:37 pm, Ketrien I. Saihr-Kenchedra wrote: ... Managed to salvage the LOR ... This is because the driver in this case is holding a lock across ...
      (freebsd-current)
    • Re: LOR in Jan16 -CUR, ACPI related possibly
      ... On Sunday 16 January 2005 04:37 pm, Ketrien I. Saihr-Kenchedra wrote: ... Managed to salvage the LOR ... This is because the driver in this case is holding a lock across ...
      (freebsd-current)