linux-kernel - Re: [PATCH] sched: Document schedule() entry points

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <501814F0.5050008@xenotime.net>
Date:	Tue, 31 Jul 2012 10:25:04 -0700
From:	Randy Dunlap <rdunlap@...otime.net>
To:	Pekka Enberg <penberg@...nel.org>
CC:	linux-kernel@...r.kernel.org, mingo@...nel.org,
	peterz@...radead.org
Subject: Re: [PATCH] sched: Document schedule() entry points

On 07/30/2012 11:15 PM, Pekka Enberg wrote:

> This patch adds a comment on top of the schedule() function to explain
> to scheduler newbies how the main scheduler function is entered.
> 
> Explained-by: Ingo Molnar <mingo@...nel.org>
> Explained-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Signed-off-by: Pekka Enberg <penberg@...nel.org>
> ---
>  kernel/sched/core.c |   34 ++++++++++++++++++++++++++++++++++
>  1 files changed, 34 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 468bdd4..9f31bbd 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3361,6 +3361,40 @@ pick_next_task(struct rq *rq)
>  
>  /*
>   * __schedule() is the main scheduler function.
> + *
> + * The main means of driving the scheduler and thus entering this function are:
> + *
> + *   1. Explicit blocking: mutex, semaphore, waitqueue, etc.
> + *
> + *   2. TIF_NEED_RESCHED flag is checked on interrupt and userspace return
> + *      paths. For example, see arch/x86/entry_64.S.
> + *
> + *      To drive preemption between tasks, the scheduler sets the flag is set


eh?

> + *      in timer interrupt handler scheduler_tick().
> + *
> + *   3. Wakeups don't really cause entry into schedule(). They add a
> + *      task to the run-queue and that's it.
> + *
> + *      Now, if the new task added to the run-queue preempts the current
> + *      task, then the wakeup sets TIF_NEED_RESCHED and schedule() gets
> + *      called on the nearest possible occasion:
> + *
> + *       - If the kernel is preemptible (CONFIG_PREEMPT=y):
> + *
> + *         - in syscall or exception context, at the next outmost
> + *           preempt_enable(). (this might be as soon as the wake_up()'s
> + *           spin_unlock()!)
> + *
> + *         - in IRQ context, return from interrupt-handler to
> + *           preemptible context
> + *
> + *       - If the kernel is not preemptible (CONFIG_PREEMPT is not set)
> + *         then at the next:
> + *
> + *          - cond_resched() call
> + *          - explicit schedule() call
> + *          - return from syscall or exception to user-space
> + *          - return from interrupt-handler to user-space
>   */
>  static void __sched __schedule(void)
>  {



-- 
~Randy
--
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/