Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752197AbbGRNAL (ORCPT ); Sat, 18 Jul 2015 09:00:11 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:36288 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750809AbbGRNAI (ORCPT ); Sat, 18 Jul 2015 09:00:08 -0400 Date: Sat, 18 Jul 2015 15:00:04 +0200 From: Frederic Weisbecker To: Andy Lutomirski Cc: Sasha Levin , Paul McKenney , "linux-kernel@vger.kernel.org" , Peter Zijlstra , X86 ML , Rik van Riel Subject: Re: Reconciling rcu_irq_enter()/rcu_nmi_enter() with context tracking Message-ID: <20150718130003.GA1747@lerouge> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2444 Lines: 52 On Thu, Jul 16, 2015 at 06:53:15PM -0700, Andy Lutomirski wrote: > For reasons that mystify me a bit, we currently track context tracking > state separately from rcu's watching state. This results in strange > artifacts: nothing generic cause IRQs to enter CONTEXT_KERNEL, and we > can nest exceptions inside the IRQ handler (an example would be > wrmsr_safe failing), and, in -next, we splat a warning: > > https://gist.github.com/sashalevin/a006a44989312f6835e7 I don't know how it happened. But the context tracking code should be able to handle exceptions on irqs. They are supposed to be simply ignored with the in_interrupt() check on context_tracking_enter/exit(). > > I'm trying to make context tracking more exact, which will fix this > issue (the particular splat that Sasha hit shouldn't be possible when > I'm done), but I think it would be nice to unify all of this stuff. > Would it be plausible for us to guarantee that RCU state is always in > sync with context tracking state? If so, we could maybe simplify > things and have fewer state variables. RCU uses the same variables for idle and user tracking whereas context tracking only tracks user. So they are at least decoupled there. And we probably don't want RCU to use a different variable due to the overhead it brings on readers. But it could be a shifted count on the same variable. > > Doing this for NMIs might be weird. Would it make sense to have a > CONTEXT_NMI that's somehow valid even if the NMI happened while > changing context tracking state. > > Thoughts? As it stands, I think we might already be broken for real: > > Syscall -> user_exit. Perf NMI hits *during* user_exit. Perf does > copy_from_user_nmi, which can fault, causing do_page_fault to get > called, which calls exception_enter(), which can't be a good thing. I think the in_interrupt() handles that. Besides NMI has its own counter. > > RCU is okay (sort of) because of rcu_nmi_enter, but this seems very fragile. > > Thoughts? As it stands, I need to do something because -tip and thus > -next spews occasional warnings. But yeah if we can, it would be nice to use context tracking as the sole tracker that RCU can safely use. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/