From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934703AbbI2PXO (ORCPT ); Tue, 29 Sep 2015 11:23:14 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:37698 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933256AbbI2PWl (ORCPT ); Tue, 29 Sep 2015 11:22:41 -0400 Date: Tue, 29 Sep 2015 17:17:13 +0200 From: Peter Zijlstra To: Steven Rostedt 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: <20150929151713.GO3816@twins.programming.kicks-ass.net> References: <20150929092825.540553633@infradead.org> <20150929093519.930244771@infradead.org> <20150929110734.2f06e07a@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150929110734.2f06e07a@gandalf.local.home> User-Agent: Mutt/1.5.21 (2012-12-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:07:34AM -0400, Steven Rostedt wrote: > On Tue, 29 Sep 2015 11:28:28 +0200 > Peter Zijlstra 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.