From owner-freebsd-arch@FreeBSD.ORG Thu Nov 13 17:56:10 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 B1D0764E; Thu, 13 Nov 2014 17:56:10 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (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 79AD2DBB; Thu, 13 Nov 2014 17:56:10 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id v10so14901929pde.18 for ; Thu, 13 Nov 2014 09:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=+PvCPtId+UyNkrwKyVBhmiEjZy6ZJRO8OPEuba/RwOI=; b=QqZAAhPT1N2VAtZRZ8gLfAwNYRwFLyOWuz448TzPHqobeSxyLNQE6usUs55q/SC73m VSnpMF6Gf5TMdBclYUz+g6510us7v1M9JwbUFumriezPsDN9xa/IY0d8dPfjv5x4qCwE GAYRKQZscxV9oZOCcrEHWfNRinix2g/Aj/Y9ZSjyQ5iQ65q3UPm2HUDI5PeeuY+ww00q TwQp9TsUFC+sRjzwNh86BKojdr00vW/tpWrkRW2UJVvGXTNujPyO7IJGiKtBD5N83ZVH wdXJ6CvQ1Z3w2tbXHpB0hGR0eRCHhPcYhENe0xZKIuOBbZigjNaNJJkNvKyPHVugaQDw BBkA== X-Received: by 10.68.68.137 with SMTP id w9mr4283010pbt.71.1415901368371; Thu, 13 Nov 2014 09:56:08 -0800 (PST) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id ae4sm18950454pad.16.2014.11.13.09.56.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 09:56:07 -0800 (PST) References: <54647D1E.9010904@freebsd.org> <201411130948.23785.jhb@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Garrett Cooper Subject: Re: Questions about locking; turnstiles and sleeping threads Date: Thu, 13 Nov 2014 09:56:06 -0800 To: Adrian Chadd Cc: Hans Petter Selasky , Alfred Perlstein , Steve Kargl , "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: Thu, 13 Nov 2014 17:56:10 -0000 > On Nov 13, 2014, at 09:32, Adrian Chadd wrote: >=20 >> On 13 November 2014 06:48, John Baldwin wrote: >>> On Thursday, November 13, 2014 4:52:50 am Adrian Chadd wrote: >>> Hm, the more I dig into this, the more I realise it's not a 1:45am >>> question to ask. >>>=20 >>> Specifically, callout_stop_safe() takes 'safe', which says "are we >>> waiting around for this callout to finish if it started". Ie, >>> callout_drain() is callout_stop_safe(c, 1) ; callout_stop() is >>> callout_stop_safe(c, 0). >>>=20 >>> If safe is 1, then it'll potentially put the current thread to sleep >>> in order to wait for it to synchronise with the callout that's >>> running. It's sleeping with cc_lock which is the per-callwheel lock >>> and it's doing that with whatever other locks are held. That's the >>> situation which is tripping things up. >>>=20 >>> The manpage says that no locks should be held that the callout may >>> block on, which isn't the case here at all - I'm trying to grab a lock >>> in another thread that the caller _into_ the callout subsystem holds. >>> The manpage doesn't mention anything about this. Sniffle. >>=20 >> It should just say "no sleepable locks at all". And yes, callout_stop() i= s >> perfectly fine to call with locks held. It is only callout_drain() that >> should not be called, same as with bus_teardown_intr() and taskqueue_drai= n() >> (other routines that can sleep while ensuring that an asynchronous task r= un >> by another thread is stopped). >=20 > so, we should add WITNESS_WARN() to those as well? This might be related to the issue Steve Kargl brought up in the thread "shu= tdown or ACPI problem" on -current@.=