From owner-freebsd-current@FreeBSD.ORG  Sun Jan 20 16:33:06 2013
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id B70CFEA5
 for <freebsd-current@freebsd.org>; Sun, 20 Jan 2013 16:33:06 +0000 (UTC)
 (envelope-from rysto32@gmail.com)
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com
 [209.85.214.171]) by mx1.freebsd.org (Postfix) with ESMTP id 87335A9A
 for <freebsd-current@freebsd.org>; Sun, 20 Jan 2013 16:33:06 +0000 (UTC)
Received: by mail-ob0-f171.google.com with SMTP id dn14so5195395obc.30
 for <freebsd-current@freebsd.org>; Sun, 20 Jan 2013 08:33:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:x-received:in-reply-to:references:date:message-id
 :subject:from:to:cc:content-type;
 bh=anpJDWlne39PIlhi4rC1JSnYt/yV9AbuZUIpKm1zveU=;
 b=Ne+oH0beXdmZao4E2AcOMQnFX6/8MfsTb9vXEr6fn0cHCyvr4b9L6kbIpRFKQcly4V
 dHKxb3dwtTPBwfRmdgnS5iP6LlOOBrr0LxOYKaCRIKaSjBqtL0aCtGzMWZ52+bZBO3CW
 KaUgiRfLryAGi3ghvgvt6GX/zDikKGu8yDeGKro/MKTHS4FSRfV5gorm7f8dn6mX7Z/R
 Y/WEJAtX+ndou5L2ZKL7Euxq/hIbcezpr7586GkfFkklF/IpUa+DTz/UF5VxyxhwtSnk
 zqXi+2x10+2WAUJbpV7am+ZLChX9tthTmczR8GOUMlhjHgbQmlB/IuOtxN/Q7BHwr5gx
 Xmgg==
MIME-Version: 1.0
X-Received: by 10.60.172.6 with SMTP id ay6mr11765144oec.10.1358699585456;
 Sun, 20 Jan 2013 08:33:05 -0800 (PST)
Received: by 10.76.128.68 with HTTP; Sun, 20 Jan 2013 08:33:05 -0800 (PST)
In-Reply-To: <20130120102908.GC2522@kib.kiev.ua>
References: <CAFMmRNz7AQMRr2+-59702k_mr=3=DsFP9c7ejPEBC7d=4w0bTA@mail.gmail.com>
 <20130120102908.GC2522@kib.kiev.ua>
Date: Sun, 20 Jan 2013 11:33:05 -0500
Message-ID: <CAFMmRNwz8Unyr=5UULF98n8gqRr9KLTK8vv=oLEcj-j0-+krTg@mail.gmail.com>
Subject: Re: ULE can leak TDQ_LOCK() if statclock() called outside of
 critical_enter()
From: Ryan Stone <rysto32@gmail.com>
To: Konstantin Belousov <kostikbel@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.14
Cc: FreeBSD Current <freebsd-current@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Jan 2013 16:33:06 -0000

On Sun, Jan 20, 2013 at 5:29 AM, Konstantin Belousov <kostikbel@gmail.com>wrote:

> Both atrtc and hpet register the interrupt handler as the filter.
> The filters call loop enters critical section around handlers, see
> kern_intr.c:intr_event_handle(). At least on HEAD it is so, and I see
> the same code in the 8.
>

Huh, I missed that.  However, on 8.2 ipi_bitmap_handler does not do a
critical_enter() (while HEAD does), so if CPU 0 gets an IPI_STATCLOCK, we
have my bug.  I have DTrace data (from 8.2) showing a thread entering
sched_switch() from sched_balance() when called through an IPI_STATCLOCK.

I'll poke around some more in HEAD to see if there are any entry points
(maybe on other architectures) that don't do a critical section, and then
add the assertions that you suggested.