Date: Sun, 20 Jan 2013 11:33:05 -0500 From: Ryan Stone <rysto32@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: ULE can leak TDQ_LOCK() if statclock() called outside of critical_enter() Message-ID: <CAFMmRNwz8Unyr=5UULF98n8gqRr9KLTK8vv=oLEcj-j0-%2BkrTg@mail.gmail.com> In-Reply-To: <20130120102908.GC2522@kib.kiev.ua> References: <CAFMmRNz7AQMRr2%2B-59702k_mr=3=DsFP9c7ejPEBC7d=4w0bTA@mail.gmail.com> <20130120102908.GC2522@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNwz8Unyr=5UULF98n8gqRr9KLTK8vv=oLEcj-j0-%2BkrTg>