From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965046AbbI2N0J (ORCPT ); Tue, 29 Sep 2015 09:26:09 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:35686 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964919AbbI2NZ4 (ORCPT ); Tue, 29 Sep 2015 09:25:56 -0400 Date: Tue, 29 Sep 2015 15:25:53 +0200 From: Frederic Weisbecker To: Peter Zijlstra Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, oleg@redhat.com, umgwanakikbuti@gmail.com, tglx@linutronix.de, rostedt@goodmis.org Subject: Re: [RFC][PATCH 03/11] sched: Robustify preemption leak checks Message-ID: <20150929132552.GE31582@lerouge> References: <20150929092825.540553633@infradead.org> <20150929093519.930244771@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150929093519.930244771@infradead.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) > --- > 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