From owner-freebsd-arch@FreeBSD.ORG Mon Aug 29 08:29:38 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74C91106564A; Mon, 29 Aug 2011 08:29:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 894F58FC0A; Mon, 29 Aug 2011 08:29:37 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA28902; Mon, 29 Aug 2011 11:29:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QxxDr-0001Jv-Qi; Mon, 29 Aug 2011 11:29:35 +0300 Message-ID: <4E5B4DEF.9050106@FreeBSD.org> Date: Mon, 29 Aug 2011 11:29:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <4E53986B.5000804@FreeBSD.org> <4E5A099F.4060903@FreeBSD.org> <201108281127.44696.hselasky@freebsd.org> In-Reply-To: <201108281127.44696.hselasky@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: skipping locks, mutex_owned, usb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 08:29:38 -0000 on 28/08/2011 12:27 Hans Petter Selasky said the following: > On Sunday 28 August 2011 11:25:51 Andriy Gapon wrote: >> So many unconventional tricks. > > Similar code is used in the DROP_GIANT and PICKUP_GIANT macros. Thank you for pointing this out - I was unfair to the USB code. This changes my perspective of the mtx_owned issue a little bit... OTOH, it looks like DROP_GIANT/PICKUP_GIANT are used in the code paths that should not be exercised in the post-panic / dumping environment. Except, perhaps, for the sync-on-panic option, which needs to be re-worked anyways. > You might want > to check all references to mtx_owned() in the kernel, and make a set of > exceptions for post-panic code execution. $ glimpse mtx_owned | wc -l 152 This looks like a too large plate for me :-( -- Andriy Gapon