[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150821133853.GC3362@lerouge>
Date: Fri, 21 Aug 2015 15:38:53 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Andy Lutomirski <luto@...nel.org>, x86@...nel.org,
Sasha Levin <sasha.levin@...cle.com>,
Brian Gerst <brgerst@...il.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>,
Borislav Petkov <bp@...en8.de>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] x86/traps: Weaken context tracking entry assertions
On Fri, Aug 21, 2015 at 08:23:28AM +0200, Ingo Molnar wrote:
>
> * Andy Lutomirski <luto@...nel.org> wrote:
>
> > We were asserting that we were all the way in CONTEXT_KERNEL when exception
> > handlers were called. While having this be true is, I think, a nice goal (or
> > maybe a variant in which we assert that we're in CONTEXT_KERNEL or some new IRQ
> > context), we're not quite there.
> >
> > In particular, if an IRQ interrupts the SYSCALL prologue and the IRQ handler in
> > turn causes an exception, the exception entry will be called in RCU IRQ mode but
> > with CONTEXT_USER.
>
> Hm, so what harm would there be in making IRQ handlers enter CONTEXT_KERNEL?
> Would nohz-full break?
That would imply to double the calls to vtime and RCU that are already in irq
generic handlers. Now we can have a CONTEXT_IRQ flag if you guys really want to
track irqs, something that takes care of not calling the RCU and time accounting
twice.
Now exceptions can still happen on irq entry before we run the context tracking call
though. I think there will always be this kind of fragility due to the drift between
soft context tracking and real context.
>
> I'd rather have a bit more tracking overhead here than lose such useful sanity
> checks.
The RCU check should testify enough about sanity here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists