From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755043AbbI3JfK (ORCPT ); Wed, 30 Sep 2015 05:35:10 -0400 Received: from smtprelay0195.hostedemail.com ([216.40.44.195]:51839 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750768AbbI3JfE (ORCPT ); Wed, 30 Sep 2015 05:35:04 -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:1539:1593:1594:1711:1730:1747:1777:1792:2393:2553:2559:2562:3138:3139:3140:3141:3142:3352:3622:3865:3867:3871:3873:3874:5007:6261:7514:7875:10004:10400:10848:10967:11026:11232:11473:11658:11914: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: body84_6649775dd185a X-Filterd-Recvd-Size: 1753 Date: Wed, 30 Sep 2015 05:35:01 -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: [PATCH v2 07/12] sched: Robustify preemption leak checks Message-ID: <20150930053501.55ebe134@gandalf.local.home> In-Reply-To: <20150930072304.285433585@infradead.org> References: <20150930071035.514587432@infradead.org> <20150930072304.285433585@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 Wed, 30 Sep 2015 09:10:42 +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. > > 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. > > Reviewed-by: Frederic Weisbecker > Reviewed-by: Thomas Gleixner Reviewed-by: Steven Rostedt -- Steve > Signed-off-by: Peter Zijlstra (Intel) > ---