Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5300940imm; Tue, 26 Jun 2018 09:00:53 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIeqcdpCA3LSA7ok8sFa/o6BzCHRoPOSNF8j9leyOT/VV7jVj+N4N5SHb0gpUtQND4/pClL X-Received: by 2002:a17:902:7248:: with SMTP id c8-v6mr2283727pll.128.1530028853329; Tue, 26 Jun 2018 09:00:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530028853; cv=none; d=google.com; s=arc-20160816; b=kjl5RKOXOq4UWYUHREZGwftnrke84SfloydhhecnrDHeUmIijauYJnRhBbZA6/6Xl6 2c9DHEqzK1EUd96tCoKSYw5b5d6qe1oGFB7TbpZGRaYFmimIPeLhfA9Q8WwZd6T1VSpG O2or1w06dlihknGmZW1AgTnVZZ/jWeVgK2WTzjbbSwmiVB4qNihcKz9L2SuvVEWba05N Zm3WZNdoVf0ZMC0hrR2tvDGzurchIg1eNRy5FSNg//pllEColhCLzTHuUyZ7aBMO2Y45 zUP2eFB5bJMmdIRTsRDuX2lVZsUb2aYi1TMvxYkg0SbPE2P6ghqRCm+lhWT930RxXym+ NhUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=ad6SBqV66L1e0ZvEC81qDgRjZzbwk+VUFhO27FQW24k=; b=CiqkqXGuEEsxZ4u8zqK+K4jrLqGrJZRigcQHaMqQ/3ByHRFf4+LSXqb66jMbHnlzGb SFi39OvvQ7pecqusuKrcpjrUxR5pynoNwueznxGWYYibhShgFOkx+6O8sLbSBar0j2M7 CpKHhAl0H9qf+LWRbjf8wEH6gD4DwvRLXn3qM28CgIYfbuIEKRtOqVWKpj5TWxIJxMGg 4A8v2qs8nRmn0xDfzF3XGJsO6Aw906q89WS6XiL2n3fasW4iUj6Zb6W8Q5UvsMODCqx3 b5MzpxbfVSNDO7Ja5HmsvaBpKQnMRFbq1bQibzznlfk/t+RRvnCShqXB1uVAbzAXuJYk niqw== ARC-Authentication-Results: i=1; mx.google.com; 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 u123-v6si1527219pgb.414.2018.06.26.09.00.38; Tue, 26 Jun 2018 09:00:53 -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; 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 S965320AbeFZNt7 (ORCPT + 99 others); Tue, 26 Jun 2018 09:49:59 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:53012 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S933522AbeFZNt6 (ORCPT ); Tue, 26 Jun 2018 09:49:58 -0400 Received: (qmail 1716 invoked by uid 2102); 26 Jun 2018 09:49:57 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Jun 2018 09:49:57 -0400 Date: Tue, 26 Jun 2018 09:49:57 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Andrea Parri cc: linux-kernel@vger.kernel.org, , Will Deacon , Peter Zijlstra , 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 In-Reply-To: <20180626101127.GB8295@andrea> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 26 Jun 2018, Andrea Parri wrote: > > > -A write memory barrier is implied by wake_up() and co. if and only if they > > > -wake something up. The barrier occurs before the task state is cleared, and so > > > -sits between the STORE to indicate the event and the STORE to set TASK_RUNNING: > > > +A general memory barrier is executed by wake_up() if it wakes something up. > > > +If it doesn't wake anything up then a memory barrier may or may not be > > > +executed; you must not rely on it. The barrier occurs before the task state > > > +is accessed, in part., it sits between the STORE to indicate the event and > > > +the STORE to set TASK_RUNNING: > > > > Minor suggestion: Instead of "in part.", how about "that is"? > > > > (I generally find "in part." to be at least a little confusing, > > probably because "part" is itself a word and "in part" is a > > reasonably common phrase in English.) > > Mmh, the fact is that that "before the task state is accessed" does want > to include the LOAD from ->state to check for the task state (recall the > pattern in [1])...; how about if I expand "in part." to "in particular"? That would be acceptable. Alan