From owner-p4-projects@FreeBSD.ORG Thu Nov 6 11:08:22 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 6BBFA16A4D2; Thu, 6 Nov 2003 11:08:22 -0800 (PST) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4522E16A4CE; Thu, 6 Nov 2003 11:08:22 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1182643FA3; Thu, 6 Nov 2003 11:08:21 -0800 (PST) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id hA6J8H0x091904 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 6 Nov 2003 11:08:19 -0800 (PST) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: Robert Watson Date: Thu, 6 Nov 2003 11:10:15 -0800 User-Agent: KMail/1.5.3 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311061110.15196.sam@errno.com> cc: sam@freebsd.org cc: perforce@freebsd.org cc: "M. Warner Losh" Subject: Re: PERFORCE change 41566 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2003 19:08:23 -0000 On Thursday 06 November 2003 10:33 am, Robert Watson wrote: > On Thu, 6 Nov 2003, Sam Leffler wrote: > > On Thursday 06 November 2003 12:26 am, M. Warner Losh wrote: > > > In message: <200311060513.hA65Da5J091575@repoman.freebsd.org> > > > > > > Sam Leffler writes: > > > : diff reduction against head > > > : - SIS_UNLOCK(sc); > > > : (*ifp->if_input)(ifp, m); > > > : - SIS_LOCK(sc); > > > > > > does this mean that we can call if_input with our locks held? > > > > sis's lock is setup MTX_RECURSE in which case re-entry is handled. You > > only need to release the lock when you may be re-entered and it's not > > setup as recursive. I think recursive locks are bad but so long as the > > driver is setup to use them I'm not releasing them when calling up. > > However, this could potentially lead to lock order reversal between the > network stack locks and the interface lock. We know the stack will grab > lots of locks in the input routine with direct dispatch. We also know the > stack will invoke the interface output routine while holding stack > locks... I think it makes the most sense to place interface locks after > network stack locks in the lock order, which would preclude holding the > interface lock and then entering the stack. You're right; wonder why I haven't hit that. I started to go through all the drivers and do that but stopped when I realized the trip through the bridge and back into the start method was handled. Guess it's because the drivers for all my NICs release on up call. I'll sweep the drivers I can test. Sam