Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1234918 > unrolled thread

[RFC][PATCH 03/11] sched: Robustify preemption leak checks

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [RFC][PATCH 03/11] sched: Robustify preemption leak checks Peter Zijlstra <peterz@infradead.org> - 2015-09-29 11:50 +0200
    [tip:sched/core] sched/core: Robustify preemption leak checks tip-bot for Peter Zijlstra <tipbot@zytor.com> - 2015-09-29 12:40 +0200
    Re: [RFC][PATCH 03/11] sched: Robustify preemption leak checks Frederic Weisbecker <fweisbec@gmail.com> - 2015-09-29 15:30 +0200
      Re: [RFC][PATCH 03/11] sched: Robustify preemption leak checks Peter Zijlstra <peterz@infradead.org> - 2015-09-29 16:30 +0200
        Re: [RFC][PATCH 03/11] sched: Robustify preemption leak checks Frederic Weisbecker <fweisbec@gmail.com> - 2015-09-29 16:40 +0200
    Re: [RFC][PATCH 03/11] sched: Robustify preemption leak checks Steven Rostedt <rostedt@goodmis.org> - 2015-09-29 17:10 +0200
      Re: [RFC][PATCH 03/11] sched: Robustify preemption leak checks Peter Zijlstra <peterz@infradead.org> - 2015-09-29 17:30 +0200

#1234918 — [RFC][PATCH 03/11] sched: Robustify preemption leak checks

When we warn about a preempt_count leak; reset the preempt_count to
the known good value such that the problem does not ripple forward.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 kernel/exit.c       |    4 +++-
 kernel/sched/core.c |    4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -706,10 +706,12 @@ void do_exit(long code)
 	smp_mb();
 	raw_spin_unlock_wait(&tsk->pi_lock);
 
-	if (unlikely(in_atomic()))
+	if (unlikely(in_atomic())) {
 		pr_info("note: %s[%d] exited with preempt_count %d\n",
 			current->comm, task_pid_nr(current),
 			preempt_count());
+		preempt_count_set(PREEMPT_ENABLED);
+	}
 
 	/* sync mm's RSS info before statistics gathering */
 	if (tsk->mm)
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2960,8 +2960,10 @@ static inline void schedule_debug(struct
 	 * schedule() atomically, we ignore that path. Otherwise whine
 	 * if we are scheduling when we should not.
 	 */
-	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD))
+	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD)) {
 		__schedule_bug(prev);
+		preempt_count_set(PREEMPT_DISABLED);
+	}
 	rcu_sleep_check();
 
 	profile_hit(SCHED_PROFILING, __builtin_return_address(0));


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1234958 — [tip:sched/core] sched/core: Robustify preemption leak checks

Commit-ID:  185b42420b0948dfc00af6cc5d93aa00b7fef581
Gitweb:     http://git.kernel.org/tip/185b42420b0948dfc00af6cc5d93aa00b7fef581
Author:     Peter Zijlstra <peterz@infradead.org>
AuthorDate: Tue, 29 Sep 2015 11:28:28 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Tue, 29 Sep 2015 12:27:40 +0200

sched/core: Robustify preemption leak checks

When we warn about a preempt_count leak; reset the preempt_count
to the known good value such that the problem does not ripple
forward.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: fweisbec@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: oleg@redhat.com
Cc: rostedt@goodmis.org
Cc: umgwanakikbuti@gmail.com
Link: http://lkml.kernel.org/r/20150929093519.930244771@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/exit.c       | 4 +++-
 kernel/sched/core.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index ea95ee1..443677c 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -706,10 +706,12 @@ void do_exit(long code)
 	smp_mb();
 	raw_spin_unlock_wait(&tsk->pi_lock);
 
-	if (unlikely(in_atomic()))
+	if (unlikely(in_atomic())) {
 		pr_info("note: %s[%d] exited with preempt_count %d\n",
 			current->comm, task_pid_nr(current),
 			preempt_count());
+		preempt_count_set(PREEMPT_ENABLED);
+	}
 
 	/* sync mm's RSS info before statistics gathering */
 	if (tsk->mm)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ecd585c..d1dec5d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2953,8 +2953,10 @@ static inline void schedule_debug(struct task_struct *prev)
 	 * schedule() atomically, we ignore that path. Otherwise whine
 	 * if we are scheduling when we should not.
 	 */
-	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD))
+	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD)) {
 		__schedule_bug(prev);
+		preempt_count_set(PREEMPT_DISABLED);
+	}
 	rcu_sleep_check();
 
 	profile_hit(SCHED_PROFILING, __builtin_return_address(0));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1235055

On Tue, Sep 29, 2015 at 11:28:28AM +0200, Peter Zijlstra wrote:
> When we warn about a preempt_count leak; reset the preempt_count to
> the known good value such that the problem does not ripple forward.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>  kernel/exit.c       |    4 +++-
>  kernel/sched/core.c |    4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -706,10 +706,12 @@ void do_exit(long code)
>  	smp_mb();
>  	raw_spin_unlock_wait(&tsk->pi_lock);
>  
> -	if (unlikely(in_atomic()))
> +	if (unlikely(in_atomic())) {
>  		pr_info("note: %s[%d] exited with preempt_count %d\n",
>  			current->comm, task_pid_nr(current),
>  			preempt_count());
> +		preempt_count_set(PREEMPT_ENABLED);
> +	}
>  
>  	/* sync mm's RSS info before statistics gathering */
>  	if (tsk->mm)
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2960,8 +2960,10 @@ static inline void schedule_debug(struct
>  	 * schedule() atomically, we ignore that path. Otherwise whine
>  	 * if we are scheduling when we should not.
>  	 */
> -	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD))
> +	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD)) {
>  		__schedule_bug(prev);
> +		preempt_count_set(PREEMPT_DISABLED);

That one would be a bit fragile if we kept PREEMPT_ACTIVE, but since we are removing
it...

Reviewed-by: Frederic Weisbecker <fweisbec@gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1235158

On Tue, Sep 29, 2015 at 03:25:53PM +0200, Frederic Weisbecker wrote:
> On Tue, Sep 29, 2015 at 11:28:28AM +0200, Peter Zijlstra wrote:

> > +	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD)) {
> >  		__schedule_bug(prev);
> > +		preempt_count_set(PREEMPT_DISABLED);
> 
> That one would be a bit fragile if we kept PREEMPT_ACTIVE, but since we are removing
> it...

Right, let me move this patch after 7 (the one that stops setting
PREEMPT_ACTIVE).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1235165

On Tue, Sep 29, 2015 at 04:24:00PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 29, 2015 at 03:25:53PM +0200, Frederic Weisbecker wrote:
> > On Tue, Sep 29, 2015 at 11:28:28AM +0200, Peter Zijlstra wrote:
> 
> > > +	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD)) {
> > >  		__schedule_bug(prev);
> > > +		preempt_count_set(PREEMPT_DISABLED);
> > 
> > That one would be a bit fragile if we kept PREEMPT_ACTIVE, but since we are removing
> > it...
> 
> Right, let me move this patch after 7 (the one that stops setting
> PREEMPT_ACTIVE).

Perfect!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1235205

On Tue, 29 Sep 2015 11:28:28 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> When we warn about a preempt_count leak; reset the preempt_count to
> the known good value such that the problem does not ripple forward.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>  kernel/exit.c       |    4 +++-
>  kernel/sched/core.c |    4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -706,10 +706,12 @@ void do_exit(long code)
>  	smp_mb();
>  	raw_spin_unlock_wait(&tsk->pi_lock);
>  
> -	if (unlikely(in_atomic()))
> +	if (unlikely(in_atomic())) {
>  		pr_info("note: %s[%d] exited with preempt_count %d\n",
>  			current->comm, task_pid_nr(current),
>  			preempt_count());
> +		preempt_count_set(PREEMPT_ENABLED);
> +	}

Looks good.

>  
>  	/* sync mm's RSS info before statistics gathering */
>  	if (tsk->mm)
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2960,8 +2960,10 @@ static inline void schedule_debug(struct
>  	 * schedule() atomically, we ignore that path. Otherwise whine
>  	 * if we are scheduling when we should not.
>  	 */
> -	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD))
> +	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD)) {
>  		__schedule_bug(prev);
> +		preempt_count_set(PREEMPT_DISABLED);
> +	}

Of course, if this was not a preemption leak, but something that called
schedule within a preempt_disable()/preempt_enable() section, when it
returns, preemption will be enabled, right?

-- Steve


>  	rcu_sleep_check();
>  
>  	profile_hit(SCHED_PROFILING, __builtin_return_address(0));
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1235231

On Tue, Sep 29, 2015 at 11:07:34AM -0400, Steven Rostedt wrote:
> On Tue, 29 Sep 2015 11:28:28 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:

> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -2960,8 +2960,10 @@ static inline void schedule_debug(struct
> >  	 * schedule() atomically, we ignore that path. Otherwise whine
> >  	 * if we are scheduling when we should not.
> >  	 */
> > -	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD))
> > +	if (unlikely(in_atomic_preempt_off() && prev->state != TASK_DEAD)) {
> >  		__schedule_bug(prev);
> > +		preempt_count_set(PREEMPT_DISABLED);
> > +	}
> 
> Of course, if this was not a preemption leak, but something that called
> schedule within a preempt_disable()/preempt_enable() section, when it
> returns, preemption will be enabled, right?

Indeed.. But it ensures only the task that incorrectly called schedule()
gets screwed and not everybody else.

This is most important on x86 which has a per cpu preempt_count that is
not saved/restored (after this series). So if you schedule with an
invalid (!2*PREEMPT_DISABLE_OFFSET) preempt_count the next task is
messed up too.

Enforcing this invariant limits the borkage to just the one task.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web