From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932334AbbI2PHo (ORCPT ); Tue, 29 Sep 2015 11:07:44 -0400 Received: from smtprelay0117.hostedemail.com ([216.40.44.117]:51781 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754256AbbI2PHi (ORCPT ); Tue, 29 Sep 2015 11:07:38 -0400 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::::::::,RULES_HIT:41:355:379:541:599:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2393:2553:2559:2562:2693:3138:3139:3140:3141:3142:3353:3622:3865:3866:3867:3872:3874:4250:4605:5007:6117:6119:6261:7774:7875:7903:10004:10400:10848:10967:11026:11232:11658:11914:12043:12296:12438:12517:12519:12740:13069:13311:13357:14096:14097:21080,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0 X-HE-Tag: sleet16_2522c49615b38 X-Filterd-Recvd-Size: 2676 Date: Tue, 29 Sep 2015 11:07:34 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, fweisbec@gmail.com, oleg@redhat.com, umgwanakikbuti@gmail.com, tglx@linutronix.de Subject: Re: [RFC][PATCH 03/11] sched: Robustify preemption leak checks Message-ID: <20150929110734.2f06e07a@gandalf.local.home> In-Reply-To: <20150929093519.930244771@infradead.org> References: <20150929092825.540553633@infradead.org> <20150929093519.930244771@infradead.org> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 29 Sep 2015 11:28:28 +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); > + } 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)); >