Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755723AbcCNNkr (ORCPT ); Mon, 14 Mar 2016 09:40:47 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:43095 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754833AbcCNNkp (ORCPT ); Mon, 14 Mar 2016 09:40:45 -0400 Date: Mon, 14 Mar 2016 14:40:38 +0100 From: Peter Zijlstra To: Davidlohr Bueso Cc: tglx@linutronix.de, mingo@kernel.org, bigeasy@linutronix.de, umgwanakikbuti@gmail.com, paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock Message-ID: <20160314134038.GZ6356@twins.programming.kicks-ass.net> References: <1457461223-4301-1-git-send-email-dave@stgolabs.net> <20160308220539.GB4404@linux-uzut.site> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160308220539.GB4404@linux-uzut.site> 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 Content-Length: 1263 Lines: 30 On Tue, Mar 08, 2016 at 02:05:39PM -0800, Davidlohr Bueso wrote: > The very nature of rt_mutex_handle_deadlock() implies that this > patch is merely a formality, as in practice the saved barrier > is of little use. That said, we can relax setting the task state > and be done with it; blocking unconditionally... this is a deadlock! > > Signed-off-by: Davidlohr Bueso > --- > kernel/locking/rtmutex.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c > index 8eb99b7f1ac8..c3d3c8e8ea5c 100644 > --- a/kernel/locking/rtmutex.c > +++ b/kernel/locking/rtmutex.c > @@ -1216,7 +1216,7 @@ static void rt_mutex_handle_deadlock(int res, int detect_deadlock, > */ > rt_mutex_print_deadlock(w); > while (1) { > - set_current_state(TASK_INTERRUPTIBLE); > + __set_current_state(TASK_INTERRUPTIBLE); > schedule(); So you're right that it doesn't matter here, however for that very reason I would suggest not using __set_current_state() before schedule() unless there is a _really_ good reason, and then with an extensive comment to go with. Otherwise people will manage to pick this as an example to copy and who all knows what kind of borkage will result from that.