public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Li Zhong <zhong@linux.vnet.ibm.com>
Subject: Re: [PATCH] context_tracking: Add comments on interface and internals
Date: Thu, 13 Dec 2012 13:18:09 -0800	[thread overview]
Message-ID: <20121213131809.122fdd61.akpm@linux-foundation.org> (raw)
In-Reply-To: <1355432225-5878-1-git-send-email-fweisbec@gmail.com>

On Thu, 13 Dec 2012 21:57:05 +0100
Frederic Weisbecker <fweisbec@gmail.com> wrote:

> This subsystem lacks many explanations on its purpose and
> design. Add these missing comments.

Thanks, it helps.

> --- a/kernel/context_tracking.c
> +++ b/kernel/context_tracking.c
> @@ -1,3 +1,19 @@
> +/*
> + * Context tracking: Probe on high level context boundaries such as kernel
> + * and userspace. This includes syscalls and exceptions entry/exit.
> + *
> + * This is used by RCU to remove its dependency to the timer tick while a CPU
> + * runs in userspace.

"on the timer tick"

> + *
> + *  Started by Frederic Weisbecker:
> + *
> + * Copyright (C) 2012 Red Hat, Inc., Frederic Weisbecker <fweisbec@redhat.com>
> + *
> + * Many thanks to Gilad Ben-Yossef, Paul McKenney, Ingo Molnar, Andrew Morton,
> + * Steven Rostedt, Peter Zijlstra for suggestions and improvements.
> + *
> + */
> +
>  #include <linux/context_tracking.h>
>  #include <linux/rcupdate.h>
>  #include <linux/sched.h>
> @@ -6,8 +22,8 @@
>  
>  struct context_tracking {
>  	/*
> -	 * When active is false, hooks are not set to
> -	 * minimize overhead: TIF flags are cleared
> +	 * When active is false, hooks are unset in order
> +	 * to minimize overhead: TIF flags are cleared
>  	 * and calls to user_enter/exit are ignored. This
>  	 * may be further optimized using static keys.
>  	 */
> @@ -24,6 +40,16 @@ static DEFINE_PER_CPU(struct context_tracking, context_tracking) = {
>  #endif
>  };
>  
> +/**
> + * user_enter - Inform the context tracking that the CPU is going to
> + *              enter in userspace mode.

s/in //

> + *
> + * This function must be called right before we switch from the kernel
> + * to the user space, when the last remaining kernel instructions to execute

s/the user space/userspace/

> + * are low level arch code that perform the resuming to userspace.

This is a bit vague - what is "right before"?  What happens if this is
done a few instructions early?  I mean, what exactly is the requirement
here?  Might it be something like "after the last rcu_foo operation"?

IOW, if the call to user_enter() were moved earlier and earlier, at
what point would the kernel gain a bug?  What caused that bug?

> + * This call supports re-entrancy.

Presumably the explanation for user_exit() applies here.

> + */
>  void user_enter(void)
>  {
>  	unsigned long flags;
> @@ -39,40 +65,68 @@ void user_enter(void)
>  	if (in_interrupt())
>  		return;
>  
> +	/* Kernel thread aren't supposed to go to userspace */

s/thread/threads/

>  	WARN_ON_ONCE(!current->mm);
>  
>  	local_irq_save(flags);
>  	if (__this_cpu_read(context_tracking.active) &&
>  	    __this_cpu_read(context_tracking.state) != IN_USER) {
>  		__this_cpu_write(context_tracking.state, IN_USER);
> +		/*
> +		 * At this stage, only low level arch entry code remains and
> +		 * then we'll run in userspace. We can assume there won't we

s/we/be/

> +		 * any RCU read-side critical section until the next call to
> +		 * user_exit() or rcu_irq_enter(). Let's remove RCU's dependency
> +		 * on the tick.
> +		 */
>  		rcu_user_enter();
>  	}
>  	local_irq_restore(flags);
>  }
>  
> +
> +/**
> + * user_exit - Inform the context tracking that the CPU is
> + *             exiting userspace mode and entering the kernel.
> + *
> + * This function must be called right before we run any high level kernel
> + * code (ie: anything that is not low level arch entry code) after we entered
> + * the kernel from userspace.

Also a very vague spec.

> + * This call supports re-entrancy. This way it can be called from any exception
> + * handler without bothering to know if we come from userspace or not.

s/bothering/needing/

s/come/came/

> + */
>  void user_exit(void)
>  {
>  	unsigned long flags;
>  
> -	/*
> -	 * Some contexts may involve an exception occuring in an irq,
> -	 * leading to that nesting:
> -	 * rcu_irq_enter() rcu_user_exit() rcu_user_exit() rcu_irq_exit()
> -	 * This would mess up the dyntick_nesting count though. And rcu_irq_*()
> -	 * helpers are enough to protect RCU uses inside the exception. So
> -	 * just return immediately if we detect we are in an IRQ.
> -	 */
>  	if (in_interrupt())
>  		return;
>  
>  	local_irq_save(flags);
>  	if (__this_cpu_read(context_tracking.state) == IN_USER) {
>  		__this_cpu_write(context_tracking.state, IN_KERNEL);
> +		/*
> +		 * We are going to run code that may use RCU. Inform
> +		 * RCU core about that (ie: we may need the tick again).
> +		 */
>  		rcu_user_exit();
>  	}
>  	local_irq_restore(flags);
>  }
>  
> +
> +/**
> + * context_tracking_task_switch - context switch the syscall hooks
> + *
> + * The context tracking uses the syscall slow path to implement its user-kernel
> + * boundaries hooks on syscalls. This way it doesn't impact the syscall fast
> + * path on CPUs that don't do context tracking.
> + *
> + * But we need to clear the flag on the previous task because it may later
> + * migrate to some CPU that doesn't do the context tracking. As such the TIF
> + * flag may not be desired there.
> + */
>  void context_tracking_task_switch(struct task_struct *prev,
>  			     struct task_struct *next)
>  {

It's mainly this bit which makes me wonder why the code is in lib/.  Is
there any conceivable prospect that any other subsystem will use this
code for anything?



  reply	other threads:[~2012-12-13 21:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-13 20:57 [PATCH] context_tracking: Add comments on interface and internals Frederic Weisbecker
2012-12-13 21:18 ` Andrew Morton [this message]
2012-12-13 22:50   ` Frederic Weisbecker
2012-12-13 23:00     ` Andrew Morton
2012-12-13 23:10       ` Frederic Weisbecker
  -- strict thread matches above, loose matches on Subject: below --
2013-01-16 12:32 Frederic Weisbecker
2013-01-16 13:04 ` Namhyung Kim
2013-01-16 14:58   ` 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=20121213131809.122fdd61.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=gilad@benyossef.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=zhong@linux.vnet.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox