From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 09:14:15 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0786F16A4BF; Wed, 20 Aug 2003 09:14:15 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D63943FBD; Wed, 20 Aug 2003 09:14:14 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7KGE77N026653 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Aug 2003 09:14:13 -0700 (PDT) (envelope-from sam@errno.com) Date: Wed, 20 Aug 2003 09:14:19 -0700 From: Sam Leffler To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Message-ID: <509542533.1061370859@melange.errno.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: CFR: routing table locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 16:14:15 -0000 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