Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755339AbbBTS6M (ORCPT ); Fri, 20 Feb 2015 13:58:12 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:53983 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754974AbbBTS6K (ORCPT ); Fri, 20 Feb 2015 13:58:10 -0500 Date: Fri, 20 Feb 2015 19:58:00 +0100 From: Peter Zijlstra To: Sergei Shtylyov Cc: Fabian Frederick , linux-kernel@vger.kernel.org, Ingo Molnar , Greg Kroah-Hartman , "Jan \"Yenya\" Kasprzak" , netdev@vger.kernel.org Subject: Re: [PATCH 6/7 linux-next] wan: cosa: replace current->state by set_current_state() Message-ID: <20150220185800.GR2896@worktop.programming.kicks-ass.net> References: <1424455977-21903-1-git-send-email-fabf@skynet.be> <1424455977-21903-6-git-send-email-fabf@skynet.be> <54E77E34.6050909@cogentembedded.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E77E34.6050909@cogentembedded.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1459 Lines: 46 On Fri, Feb 20, 2015 at 09:34:28PM +0300, Sergei Shtylyov wrote: > Hello. > > On 02/20/2015 09:12 PM, Fabian Frederick wrote: > > >Use helper functions to access current->state. > >Direct assignments are prone to races and therefore buggy. > > >current->state = TASK_RUNNING is replaced by __set_current_state() > > You sometimes use __set_current_state() and sometimes set_current_state(). It depends on which state; setting yourself TASK_RUNNING is free of wakeup races -- you're already running after all, so it can safely use __set_current_state(). Setting a blocking state otoh needs set_current_state() which issues a full memory barriers with the store (critically in this case, effectively after the store) such that it orders the state store with a subsequent load in the condition check if it really needs to go to sleep. In full: current->state = TASK_UNINTERRUPTIBLE; wait = false; smp_mb(); smp_wmb(); if (wait) p->state = TASK_RUNNING; schedule(); Without that smp_mb(); the following order is possible: if (wait) wait = false; smp_wmb(); p->state = TASK_RUNNING; current->state = TASK_UNINTERRUPTIBLE; schedule(); And we'll wait forever more.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/