From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 09:31:17 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D52BD81F; Fri, 14 Nov 2014 09:31:17 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id BAC69A3D; Fri, 14 Nov 2014 09:31:17 +0000 (UTC) Received: from [10.0.1.20] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 7411B341F877; Fri, 14 Nov 2014 01:31:17 -0800 (PST) Subject: Re: Questions about locking; turnstiles and sleeping threads Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alfred Perlstein In-Reply-To: Date: Fri, 14 Nov 2014 01:31:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141112212613.21037929@kan> <546472DA.3080006@freebsd.org> <5464764E.9080308@freebsd.org> <54647D1E.9010904@freebsd.org> <54648483.5060107@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1283) Cc: Hans Petter Selasky , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 09:31:17 -0000 On Nov 13, 2014, at 9:31 AM, Adrian Chadd wrote: > On 13 November 2014 02:14, Alfred Perlstein = wrote: >> Would need more context to help on this. >>=20 >> I can't tell based on your description which thread is holding which = lock. >>=20 >> If A is waiting for callout C to stop AND there exists a thread B = that is >> contending against C for a lock, you should be fine so long as there = is no >> lock cycle against A. >>=20 >> Would be best if you pointed at some code and gave descriptions. >=20 > I haven't dug into the USB side of things ,but on the atheros side I > gave the description above. >=20 > Thread A grabs lock X and tries to drain callout, which involves > grabbing lock Y to do the dirty work. Lock Y isn't held at this point > - the callout is about to run or is running, so it enters the sleepq > call to finish the drain. >=20 > Thread B wants to grab lock X, but can't because thread A holds lock X > and is in a sleepq due to callout_drain(). Hence panic. >=20 > I'll poke people on IRC today and see if I can get a better > description of what/where the WITNESS_WARN() should be placed in > callout_drain(). Then we'll see what's left triggering it. Yes, this is exactly how one is not supposed to use callout_drain(). =46rom the context of the caller of callout_drain() you are better off = doing a stop() under the lock, then dropping the lock and doing the = drain. Typically one sets a "dying" or "going away" type flag in the = softc to prevent more callouts from being scheduled. -Alfred