Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1299860ybl; Fri, 16 Aug 2019 12:22:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqyndZKpOQ7TQFnP29eI8LEAWNFXHkWxd7Yifhs34mDs/Hyixn768isGRmb0SvHrfGNCdDMk X-Received: by 2002:a17:902:aa08:: with SMTP id be8mr11012933plb.144.1565983335439; Fri, 16 Aug 2019 12:22:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565983335; cv=none; d=google.com; s=arc-20160816; b=BwkydIlpLbDBvg1RSlLLiFVgzU3uAPCBQWVB3I2FbjMtkmxGh5Rnh/IkyUXkgTUS5I oJ4I4WjOozXv0xEk47tK43M7jushyJ/YNqyLXrfvxAt5rKVUzj/irhnuOifqczINkAb5 IYmFHEm3G7g8wv/Anj2Ss/2/7Hn+mDyVv4aN5C7QfN5IuyMhDlpQRTb2QA0J6rP29gdG 3NLB/1De6jyr4ZmvJNQpO7hDjxUrVphG6daXhs3OzqmscIAVgNF8KddKOJfiYgZw5sXA ZpkCchJK17Pr5jb0UH+W6tscfh5H5GD+oywXY9bKuYkwIPC2wzYIJXD8ddMFQH0v1I/c q4Ng== 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; bh=/6U7siZ8wCXWpgnoDrylnLwR4S5yg+7XgvBn7PXbyYw=; b=xSiVK/ntExPoFJNlwL1hGEmSzzD/DGfqcvZU+YDyFOvOhqSquVdyz/TG64S3HUZ8J5 ApdeQPjfYenJpd387KhvmYYNOLlDFZXLP/2RFmAh+QHYaXaVijSGGtOrVVR+42ckClPp 25FRqcxvUBNwzbzvrnTnfsIeq7xPBYE2/5OhftVzmBJzrVLtzdYk0O8Kmbgr/vxdRv72 oFCu2LvUECLytCNzZExiZ+8AKX0/tWbVaKEN4QnFbHUyStSvJsJPcU1p1S3wVBFlOLtY 8xFXElaOhPr7ZJnvzuXczMi3kSibBISYVcxEd9VH1TDfLb39WW11CDqKS7tUrmQpNQ+z vhog== 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 f26si4776340pfd.193.2019.08.16.12.21.59; Fri, 16 Aug 2019 12:22:15 -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 S1727633AbfHPTTo (ORCPT + 99 others); Fri, 16 Aug 2019 15:19:44 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:58434 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726527AbfHPTTo (ORCPT ); Fri, 16 Aug 2019 15:19:44 -0400 Received: (qmail 4672 invoked by uid 2102); 16 Aug 2019 15:19:43 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Aug 2019 15:19:43 -0400 Date: Fri, 16 Aug 2019 15:19:43 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Mathieu Desnoyers cc: rostedt , Valentin Schneider , linux-kernel , "Joel Fernandes, Google" , Peter Zijlstra , Thomas Gleixner , paulmck , Boqun Feng , Will Deacon , David Howells , Linus Torvalds Subject: Re: [PATCH 1/1] Fix: trace sched switch start/stop racy updates In-Reply-To: <241506096.21688.1565977319832.JavaMail.zimbra@efficios.com> 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 Fri, 16 Aug 2019, Mathieu Desnoyers wrote: > If you choose not to use READ_ONCE(), then the "load tearing" issue can > cause similar spurious 1 -> 0 -> 1 transitions near 16-bit counter > overflow as described above. The "Invented load" also becomes an issue, > because the compiler could use the loaded value for a branch, and re-load > that value between two branches which are expected to use the same value, > effectively generating a corrupted state. > > I think we need a statement about whether READ_ONCE/WRITE_ONCE should > be used in this kind of situation, or if we are fine dealing with the > awkward compiler side-effects when they will occur. The only real downside (apart from readability) of READ_ONCE and WRITE_ONCE is that they prevent the compiler from optimizing accesses to the location being read or written. But if you're just doing a single access in each place, not multiple accesses, then there's nothing to optimize anyway. So there's no real reason not to use READ_ONCE or WRITE_ONCE. Alan Stern