From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 04:03:41 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA2D716A420; Sun, 28 Aug 2005 04:03:41 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B81943D45; Sun, 28 Aug 2005 04:03:41 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j7S42iA5021295; Sat, 27 Aug 2005 22:02:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 27 Aug 2005 22:03:03 -0600 (MDT) Message-Id: <20050827.220303.130848154.imp@bsdimp.com> To: rwatson@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20050828025721.X43518@fledge.watson.org> References: <20050827184153.A24510@fledge.watson.org> <20050827.124941.14976142.imp@bsdimp.com> <20050828025721.X43518@fledge.watson.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.village.org [127.0.0.1]); Sat, 27 Aug 2005 22:02:49 -0600 (MDT) Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, dandee@volny.cz Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2005 04:03:42 -0000 In message: <20050828025721.X43518@fledge.watson.org> Robert Watson writes: : : On Sat, 27 Aug 2005, M. Warner Losh wrote: : : > : You need to add an entry to subr_witness.c creating a graph edge between : > : the softc lock and the routing lock. An example of an entry in : > : subr_witness.c: : > : : > : /* : > : * TCP/IP : > : */ : > : { "tcp", &lock_class_mtx_sleep }, : > : { "tcpinp", &lock_class_mtx_sleep }, : > : { "so_snd", &lock_class_mtx_sleep }, : > : { NULL, NULL }, : > : : > : Note that sets of ordered entries are terminated with a double-null. This : > : declares that locks of type "tcp" preceed "tcpinp" which preceed : > : "so_snd". : > : > So you have to have locks of type tcp BEFORE you take out tcpinp type : > locks? : : Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, and : 'tcpinp' is for individual PCBs. If you acquire first a tcpinp and then : tcp, the above settings should cause WITNESS to generate a lock order : warning. Likewise, both tcp and tcpinp preceed so_snd, so if you acquire : a protocol lock after a socket lock, it will get unhappy. WITNESS handles : transitive relationships, so it gets connected up to the rest of the lock : graph, explicit and implicit, so indirect violations of orders are fully : handled. OK. I've been seeing similar LORs in ed, sn, iwi (ed is my locked version of ed, not in tree GIANT locked ed). I've made the following changes, and the LORs go away (except for one, which was unrelated). I further don't get the first place where they locks happen that caused the original LORs, so I'm mightly confused. ==== //depot/user/imp/newcard/kern/subr_witness.c#62 - /dell/imp/p4/newcard/src/sys/kern/subr_witness.c ==== @@ -273,6 +273,13 @@ { "allprison", &lock_class_mtx_sleep }, { NULL, NULL }, /* + * Network driver locking order + */ + { "rawinp", &lock_class_mtx_sleep }, + { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, + { "if_addr_mtx", &lock_class_mtx_sleep }, + { NULL, NULL }, + /* * Sockets */ { "filedesc structure", &lock_class_mtx_sleep }, @@ -309,6 +316,7 @@ { "udp", &lock_class_mtx_sleep }, { "udpinp", &lock_class_mtx_sleep }, { "so_snd", &lock_class_mtx_sleep }, + { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, { NULL, NULL }, /* * TCP/IP @@ -316,6 +324,7 @@ { "tcp", &lock_class_mtx_sleep }, { "tcpinp", &lock_class_mtx_sleep }, { "so_snd", &lock_class_mtx_sleep }, + { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, { NULL, NULL }, /* * SLIP I'm not sure if I need to add the if_addr_mtx after each thing or not. Clearly I've done something wrong :-(. I just don't see what. Warner