All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Phil Auld <pauld@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH 2/5] context_tracking:  Don't implement exception_enter/exit() on CONFIG_HAVE_CONTEXT_TRACKING_OFFSTACK
Date: Wed, 11 Nov 2020 23:20:39 +0100	[thread overview]
Message-ID: <20201111222039.GA73739@lothringen> (raw)
In-Reply-To: <20201111143218.GU2611@hirez.programming.kicks-ass.net>

On Wed, Nov 11, 2020 at 03:32:18PM +0100, Peter Zijlstra wrote:
> On Tue, Oct 27, 2020 at 04:08:24PM +0100, Frederic Weisbecker wrote:
> > An architecture that provides this Kconfig feature doesn't need to
> > store the context tracking state on the task stack because its entry
> > code has been sanitized such that fragile path aren't preemptible
> > and special use of tracing and RCU read side critical sections in these
> > areas have been explicitly annotated.
> > 
> > Hence the exception_enter()/exception_exit() couple doesn't need to be
> > implemented in this case.
> 
> Could you please explain what exception_{enter,exit}() actually do, then
> explain what is required to make it superfluous? Because as is, I don't
> have enough information to verify the claims made.

So, the typical steps with context tracking are:

1) Task runs in userspace
2) Task enters the kernel (syscall/exception/IRQ)
3) Task switches from context tracking state CONTEXT_USER to CONTEXT_KERNEL (user_exit())
4) Task does stuff in kernel
5) Task switches from context tracking state CONTEXT_KERNEL to CONTEXT_USER (user_enter())
6) Task exits the kernel

If an exception fires between 5) and 6), the pt_regs and the context tracking disagree
on the context of the origin. We must set CONTEXT_KERNEL before the exception handler,
that's unconditional for those that want to call into schedule, but we must restore
CONTEXT_USER when we exit the exception while pt_regs tells us that we are resuming to
kernel space.

We can't fix that with storing the context tracking state in a per-cpu or per-task variable
since another exception may fire onto the current one and overwrite the saved state. Also
the task can schedule. So it has to be stored in a per task stack.

This is how exception_enter()/exception_exit() papers over the problem:

5) Task switches from context tracking state CONTEXT_KERNEL to CONTEXT_USER (user_enter())
5.1) Exception fires
5.2) prev_state = exception_enter() // save CONTEXT_USER to prev_state and set CONTEXT_KERNEL
5.3) Exception handler
5.4) exception_enter(prev_state) // restore CONTEXT_USER
5.5) Exception resumes
6) Task exits the kernel

What is required to make it superfluous is to forbid exceptions and IRQs between 2) and 3)
and between 5) and 6), or if we allow any, they won't call into context tracking, eg: NMIs,
and they won't schedule.

I can add that in the changelog if that makes it any clearer.

Thanks.

  reply	other threads:[~2020-11-11 22:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-27 15:08 [PATCH 0/5] context_tracking: Flatter archs not using exception_enter/exit() v2 Frederic Weisbecker
2020-10-27 15:08 ` [PATCH 1/5] context_tracking: Introduce HAVE_CONTEXT_TRACKING_OFFSTACK Frederic Weisbecker
2020-10-27 15:08 ` [PATCH 2/5] context_tracking: Don't implement exception_enter/exit() on CONFIG_HAVE_CONTEXT_TRACKING_OFFSTACK Frederic Weisbecker
2020-11-11 14:32   ` Peter Zijlstra
2020-11-11 22:20     ` Frederic Weisbecker [this message]
2020-10-27 15:08 ` [PATCH 3/5] sched: Detect call to schedule from critical entry code Frederic Weisbecker
2020-10-27 15:08 ` [PATCH 4/5] context_tracking: Only define schedule_user() on !HAVE_CONTEXT_TRACKING_OFFSTACK archs Frederic Weisbecker
2020-11-11 14:34   ` Peter Zijlstra
2020-11-11 22:22     ` Frederic Weisbecker
2020-10-27 15:08 ` [PATCH 5/5] x86: Support HAVE_CONTEXT_TRACKING_OFFSTACK Frederic Weisbecker
  -- strict thread matches above, loose matches on Subject: below --
2020-11-17 15:16 [PATCH 0/5] context_tracking: Flatter archs not using exception_enter/exit() v3 Frederic Weisbecker
2020-11-17 15:16 ` [PATCH 2/5] context_tracking: Don't implement exception_enter/exit() on CONFIG_HAVE_CONTEXT_TRACKING_OFFSTACK Frederic Weisbecker
2020-10-05 10:49 [PATCH 0/5] context_tracking: Flatter archs not using exception_enter/exit() Frederic Weisbecker
2020-10-05 10:49 ` [PATCH 2/5] context_tracking: Don't implement exception_enter/exit() on CONFIG_HAVE_CONTEXT_TRACKING_OFFSTACK Frederic Weisbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201111222039.GA73739@lothringen \
    --to=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pauld@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.