Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5270412imm; Tue, 26 Jun 2018 08:31:45 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIAqDaLcMIfsFPmqsDslr4Ji3LwRDT4HKDKfwNqzrEhYwEaztDNw13vsGgNNTyn0Jlxy+PC X-Received: by 2002:a17:902:788e:: with SMTP id q14-v6mr2124428pll.234.1530027105332; Tue, 26 Jun 2018 08:31:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530027105; cv=none; d=google.com; s=arc-20160816; b=a6bzzFeH0Fq2Rsu7Snv9rtLF+eNlozX8PrQB+w9uEjdNlGCtOqFVXByAkxZYNl+QoU DmoyeOXdQNxzdXt85VtbHNfnkVaZiu8vesAcH8AeqUoGEnKOT4kikDkJo9DQgSOoD/NL l2W/83Vn2ffdehB7X9u2qxUiPd0VXRYWjKN1koKEj1HPPal0SlJvSrIYMazYdwpBSeyD xL7uA5E54Rw5S9ikEwuYjXuzOaWUO4Ybcr9CDJAlptCefoXhG6c0PCiV/h/UoOUiJpVI lM7sJDZnQanuNV/fZ1Aba1EAmcLniBE6I/ZeEKLF7heIQ1P9fMhvoQ8N22w9SUuWKl6y 6Btg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=4CCX95g5OocRVXIYw8EEcqFqu4FWgLlxdZJrizsnFvs=; b=Jv6jTgRd2YpXGxFoo9DKc1QlqMeE88C/OmLOaXEZ9qntlGnxqTPzXd20rzWle97Ryu dU7QMob22JssXJrIFQtUaErPpptYs+7CFTf07oyIXdqeX9C6Fm2q+9KwDylFWo8v1v8b kfiWfQp3bUURfjiukcSBDm4fC+NKvzkI0lK4EvdoZDjEiBxReY2o+4P8eYN2+9ryH4cb Y405oIMJu83R3t+6Ph9hgV5qZrq/SepD48Dvgm3MHxOEi3xHXTtyVyny/2VpJNzxGu6m Kq+5HXam4Z5YRyOvyBNoDbrDAd3ep49rFNoXUf0Wx+fj2GfsU1GyLtxVM0LPCIl5PQY2 JuHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=nN6IzVN4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f6-v6si1493069pgc.73.2018.06.26.08.31.30; Tue, 26 Jun 2018 08:31:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=nN6IzVN4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751682AbeFZPaj (ORCPT + 99 others); Tue, 26 Jun 2018 11:30:39 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:47930 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751073AbeFZPai (ORCPT ); Tue, 26 Jun 2018 11:30:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4CCX95g5OocRVXIYw8EEcqFqu4FWgLlxdZJrizsnFvs=; b=nN6IzVN4Fw1x6g8XJkUHPxU3C PIs4xKtlQYqCnWQ9lr0vJg7/1A8dvXWAMShldTiBJNgHw2h5LOBfIVWx3ebFWnmB/fY4uTY0qIEof p+RIHHQOOLZfYaJnfmn4s7LHw3Ynw18fIn9ESZvlQKJRlP2Y2DFXKmR2gsL3vxkupIcuwxGP8wK2e M/6bBPC/uj54ZXMW0qBdnAestoUk7IXqYOIZwQa689VZcDi91xy9NEvUmmwNdRAmpja4NlZK16nZX WothseLcTWTx5XO+Bl46PlyAJkwr4Cn/rdDXzz0CUs4hL7QNn7Ep6m5JyzivTKBdx95lQQMcb7JFO zcSUhWsBA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fXpvH-0008Lo-Bd; Tue, 26 Jun 2018 15:30:27 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id CF4C82029F1D7; Tue, 26 Jun 2018 17:30:25 +0200 (CEST) Date: Tue, 26 Jun 2018 17:30:25 +0200 From: Peter Zijlstra To: Andrea Parri Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Alan Stern , Will Deacon , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Jonathan Corbet , Ingo Molnar , Randy Dunlap Subject: Re: [PATCH] doc: Update wake_up() & co. memory-barrier guarantees Message-ID: <20180626153025.GD2458@hirez.programming.kicks-ass.net> References: <1529918258-7295-1-git-send-email-andrea.parri@amarulasolutions.com> <20180625095031.GX2494@hirez.programming.kicks-ass.net> <20180625105618.GA12676@andrea> <20180625123121.GY2494@hirez.programming.kicks-ass.net> <20180625131643.GA15126@andrea> <20180625141830.GC2494@hirez.programming.kicks-ass.net> <20180625145611.GA16333@andrea> <20180625163705.GE2494@hirez.programming.kicks-ass.net> <20180626100942.GA8295@andrea> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180626100942.GA8295@andrea> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 26, 2018 at 12:09:42PM +0200, Andrea Parri wrote: > > > Same RFC for the first comment: > > > > > > /* > > > * The above implies an smp_mb(), which matches with the smp_wmb() from > > > * woken_wake_function() such that if we observe WQ_FLAG_WOKEN we must > > > * also observe all state before the wakeup. > > > */ > > > > > > What is the corresponding snippet & BUG_ON()? > > > > The comment there suggest: > > > > if (condition) > > break; > > > > set_current_state(UNINTERRUPTIBLE); condition = true; > > /* smp_mb() */ smp_wmb(); > > wq_entry->flags |= WQ_FLAG_WOKEN; > > if (!wq_entry->flags & WQ_FLAG_WOKEN) > > schedule(); > > > > > > BUG_ON((wq_entry->flags & WQ_FLAG_WOKEN) && !condition); > > > > > > But looking at that now, I think that's wrong. Because the the purpose > > was that, if we don't do the try_to_wake_up(), our task still needs to > > observe the condition store. > > > > But for that we need a barrier between the wq_entry->flags load and the > > second condition test, which would (again) be B, not A. > > Agreed. Now that I stared at the code a bit more, I think that (A) is > still needed for the synchronization on "->state" and "->flags" (an SB > pattern seems again to be hidden in the call to try_to_wake_up()): > > p->state = mode; wq_entry->flags |= WQ_FLAG_WOKEN; > smp_mb(); // A try_to_wake_up(): > if (!(wq_entry->flags & WQ_FLAG_WOKEN)) > schedule() if (!(p->state & mode)) > goto out; > > BUG_ON(!(wq_entry->flags & WQ_FLAG_WOKEN) && !(p->state & mode)) > > So, I think that we should keep (A). Yes, very much so. Once we actually get to use ttwu() that barrier is required. > I am planning to send these changes (smp_mb() in woken_wake_function() > and fixes to the comments) as a separate patch. Probably makes sense. Thanks for looking at this, I have vague memories of being slightly confused when I wrote all that :-)