| 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
| ||
|
Date: Tue, 16 Aug 2011 13:44:15 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Anton Blanchard <anton@....ibm.com>,
Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>,
Lai Jiangshan <laijs@...fujitsu.com>,
Paul Menage <menage@...gle.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Stephen Hemminger <shemminger@...tta.com>,
Thomas Gleixner <tglx@...utronix.de>,
Tim Pepper <lnxninja@...ux.vnet.ibm.com>
Subject: Re: [PATCH 31/32] rcu: Switch to extended quiescent state in
userspace from nohz cpuset
On Mon, Aug 15, 2011 at 05:52:28PM +0200, Frederic Weisbecker wrote:
> When we switch to adaptive nohz mode and we run in userspace,
> we can still receive IPIs from the RCU core if a grace period
> has been started by another CPU because we need to take part
> of its completion.
>
> However running in userspace is similar to that of running in
> idle because we don't make use of RCU there, thus we can be
> considered as running in RCU extended quiescent state. The
> benefit when running into that mode is that we are not
> anymore disturbed by needless IPIs coming from the RCU core.
>
> To perform this, we just to use the RCU extended quiescent state
> APIs on the following points:
>
> - kernel exit or tick stop in userspace: here we switch to extended
> quiescent state because we run in userspace without the tick.
>
> - kernel entry or tick restart: here we exit the extended quiescent
> state because either we enter the kernel and we may make use of RCU
> read side critical section anytime, or we need the timer tick for some
> reason and that takes care of RCU grace period in a traditional way.
>
> TODO: hook into do_notify_resume() because we may have called
> rcu_enter_nohz() from syscall exit hook, but we might call
> do_notify_resume() right after, which may use RCU.
I don't see exactly how the exception path works, but this does reassure
me a bit on the syscall path.
Thanx, Paul
> Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Anton Blanchard <anton@....ibm.com>
> Cc: Avi Kivity <avi@...hat.com>
> Cc: Ingo Molnar <mingo@...e.hu>
> Cc: Lai Jiangshan <laijs@...fujitsu.com>
> Cc: Paul E . McKenney <paulmck@...ux.vnet.ibm.com>
> Cc: Paul Menage <menage@...gle.com>
> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Cc: Stephen Hemminger <shemminger@...tta.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Tim Pepper <lnxninja@...ux.vnet.ibm.com>
> ---
> include/linux/tick.h | 2 ++
> kernel/sched.c | 1 +
> kernel/time/tick-sched.c | 21 +++++++++++++++++++++
> 3 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/tick.h b/include/linux/tick.h
> index 9d0270e..4e7555f 100644
> --- a/include/linux/tick.h
> +++ b/include/linux/tick.h
> @@ -138,12 +138,14 @@ extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
>
> #ifdef CONFIG_CPUSETS_NO_HZ
> DECLARE_PER_CPU(int, task_nohz_mode);
> +DECLARE_PER_CPU(int, nohz_task_ext_qs);
>
> extern void tick_nohz_enter_kernel(void);
> extern void tick_nohz_exit_kernel(void);
> extern void tick_nohz_enter_exception(struct pt_regs *regs);
> extern void tick_nohz_exit_exception(struct pt_regs *regs);
> extern int tick_nohz_adaptive_mode(void);
> +extern void tick_nohz_cpu_exit_qs(void);
> extern bool tick_nohz_account_tick(void);
> extern void tick_nohz_flush_current_times(bool restart_tick);
> #else /* !CPUSETS_NO_HZ */
> diff --git a/kernel/sched.c b/kernel/sched.c
> index 2bcd456..576d0bf 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -2504,6 +2504,7 @@ static void cpuset_nohz_restart_tick(void)
> __get_cpu_var(task_nohz_mode) = 0;
> tick_nohz_restart_sched_tick();
> clear_thread_flag(TIF_NOHZ);
> + tick_nohz_cpu_exit_qs();
> }
>
> void cpuset_update_nohz(void)
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 9a2ba5b..b611b77 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -757,6 +757,7 @@ void tick_check_idle(int cpu)
> }
>
> #ifdef CONFIG_CPUSETS_NO_HZ
> +DEFINE_PER_CPU(int, nohz_task_ext_qs);
>
> void tick_nohz_exit_kernel(void)
> {
> @@ -783,6 +784,9 @@ void tick_nohz_exit_kernel(void)
> ts->saved_jiffies = jiffies;
> ts->saved_jiffies_whence = JIFFIES_SAVED_USER;
>
> + __get_cpu_var(nohz_task_ext_qs) = 1;
> + rcu_enter_nohz();
OK, I was wondering how this was going to work if RCU didn't
know about kernel entry/exit. Whew!!! ;-)
> +
> local_irq_restore(flags);
> }
>
> @@ -799,6 +803,11 @@ void tick_nohz_enter_kernel(void)
> return;
> }
>
> + if (__get_cpu_var(nohz_task_ext_qs) == 1) {
> + __get_cpu_var(nohz_task_ext_qs) = 0;
> + rcu_exit_nohz();
> + }
> +
> ts = &__get_cpu_var(tick_cpu_sched);
>
> WARN_ON_ONCE(ts->saved_jiffies_whence == JIFFIES_SAVED_SYS);
> @@ -814,6 +823,16 @@ void tick_nohz_enter_kernel(void)
> local_irq_restore(flags);
> }
>
> +void tick_nohz_cpu_exit_qs(void)
> +{
> + struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);
> +
> + if (__get_cpu_var(nohz_task_ext_qs)) {
> + rcu_exit_nohz();
> + __get_cpu_var(nohz_task_ext_qs) = 0;
> + }
> +}
> +
> void tick_nohz_enter_exception(struct pt_regs *regs)
> {
> if (user_mode(regs))
> @@ -858,6 +877,8 @@ static void tick_nohz_cpuset_stop_tick(int user)
> if (user) {
> ts->saved_jiffies_whence = JIFFIES_SAVED_USER;
> ts->saved_jiffies = jiffies;
> + __get_cpu_var(nohz_task_ext_qs) = 1;
> + rcu_enter_nohz();
When entering an exception, shouldn't we call rcu_exit_nohz() rather
than rcu_exit_nohz()? Or is this a "didn't really mean an exception"
code path?
> } else if (!current->mm) {
> ts->saved_jiffies_whence = JIFFIES_SAVED_SYS;
> ts->saved_jiffies = jiffies;
> --
> 1.7.5.4
>
> --
> 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/
--
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