From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 15:43:22 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E2D71C8; Fri, 14 Nov 2014 15:43:22 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05E71889; Fri, 14 Nov 2014 15:43:22 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id k14so438762wgh.38 for ; Fri, 14 Nov 2014 07:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Ejs9ELS6cCx/RacLAXHRPXhcpd8Km/Q187crGTIpGxc=; b=CtrJP+8xizvZiJ63WV0BgfGQ2Fizyy8PJopHljmLPT3XAfVeV1WBGNh6mIexbxdEgo UsZEWNYWuDW9cSrTpFceTQJCjyY1p9IQOjVXY2YGZu9+mMOf7SNWnSpduYvLj3FemIzK G5WJ0JqpuINHVgt95cpPh5vanx8CkxF5Fzv8t/VG1DFO4eLhOxVDIv6Gjw+6fyibSjvF SGkl108UdalXsl3vDI9GhZgLDo/7X3+7jI/ssg6cBiy8qMmdgOKVfhSgFPVw0AIVlVfP QH88gX2toWC37L80N2EVAxhMc+mjuH/WIZEFjK1Ijob9VYiJ5Dv1LTdfs8HknJbvKdj3 sDDg== MIME-Version: 1.0 X-Received: by 10.194.47.226 with SMTP id g2mr14871422wjn.68.1415979800361; Fri, 14 Nov 2014 07:43:20 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 14 Nov 2014 07:43:20 -0800 (PST) In-Reply-To: References: <20141112212613.21037929@kan> <546472DA.3080006@freebsd.org> <5464764E.9080308@freebsd.org> <54647D1E.9010904@freebsd.org> <54648483.5060107@freebsd.org> Date: Fri, 14 Nov 2014 07:43:20 -0800 X-Google-Sender-Auth: ILC4sPA1NBG8pxmAGIZcmTlhHVk Message-ID: Subject: Re: Questions about locking; turnstiles and sleeping threads From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 15:43:22 -0000 On 14 November 2014 01:31, Alfred Perlstein wrote: > > 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. >>> >>> I can't tell based on your description which thread is holding which lo= ck. >>> >>> 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. >>> >>> Would be best if you pointed at some code and gave descriptions. >> >> I haven't dug into the USB side of things ,but on the atheros side I >> gave the description above. >> >> 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. >> >> 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. >> >> 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(). > > From the context of the caller of callout_drain() you are better off doin= g a stop() under the lock, then dropping the lock and doing the drain. Typ= ically one sets a "dying" or "going away" type flag in the softc to prevent= more callouts from being scheduled. Right. Well, I'll see about getting a WITNESS check inserted there so no other badly behaving code creeps in. -adrian