Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1173696ybl; Thu, 12 Dec 2019 10:45:06 -0800 (PST) X-Google-Smtp-Source: APXvYqwM4Y6dSTHPtaQawp9VH9/32vho6u8Jm+bt44PGhJ3KveXc//mRrmobqtiBSd/V4PytRWMe X-Received: by 2002:a9d:366:: with SMTP id 93mr9926476otv.183.1576176306265; Thu, 12 Dec 2019 10:45:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576176306; cv=none; d=google.com; s=arc-20160816; b=uomb0Mzp4xfDUkf1eJ7iTtVAPY6JhZ9aKDoeGqfDROiD6qPnuF5WTsjV6WJWn24eHz IDwV73ljoCrxifD5LqtP4DlJPf9KJnRTOE1wLjPugwoWCYSKzwgMmSeQbUOAdMvl0Ibv OUFeGqxChIAu1eM6VAG0YF7NQsjRhs8nSkBQMcTjTm2FvrWJ41BXb0joGXRFZBftfCh9 3BYO6cLDL1VPI0m/xH4DReztp6z2YDa4xEhNVRuuXCb25XyFmFxpKCYqHDk7WIwRqoqk Eje5G5w1GDLhOfKKQ6euG2tXX8Yeoen5laqXUMCnGjKd5Uwn/anyhz+tR+ZwC5XHrMGh +dAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=daP2x4GLzegqYAtGzoN/GqQWx/OgbUZpFEmzsIb9AuY=; b=uRHarsNm6eHzKPJJm+/ZEDSYvzq8uQpuwcZKWlrrnsfB7Fdf5br/H6vZX3FfvajhSk sgTIgW6Wf4G+nlyYYEo/45A7Ptgxv10AI+ZOzYogautZd3cYSOBJ0C79osAAsgWXdOJO kxefacnxGFKUFiSZ6ZAztRVAeRrZL3KuJgPxqSWLQ1D6JcdgNSwR8czOZuzuBNw25YQU 8f/duJCbnrfzrhEol/e5Y0SC2ml4GG8q/puaOvoBPO7okwd9w2My7uD0BBI0MVQDiw/U d+Fs0+e5sC5o5Qt4Ts82tcfjSteBYJSbIUFiPVG9KyicOusYLX3UrMEnStYZnlgyW+uF Q86w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=ESVNK1Mw; 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 l9si3400276otn.301.2019.12.12.10.44.53; Thu, 12 Dec 2019 10:45:06 -0800 (PST) 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=pass header.i=@linux-foundation.org header.s=google header.b=ESVNK1Mw; 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 S1730448AbfLLSnZ (ORCPT + 99 others); Thu, 12 Dec 2019 13:43:25 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:33033 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730292AbfLLSnZ (ORCPT ); Thu, 12 Dec 2019 13:43:25 -0500 Received: by mail-lj1-f194.google.com with SMTP id 21so3448697ljr.0 for ; Thu, 12 Dec 2019 10:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=daP2x4GLzegqYAtGzoN/GqQWx/OgbUZpFEmzsIb9AuY=; b=ESVNK1Mwi4VakiBbtSIOLOxnFTfo9yicVGMiebqVDAAObXDl8gUPGjFP3V6AoTVKJc HXbX49wJTIP8gVq4DIOHImreynSyKqrAyaVA413Sj66yFki8qzqdppnMRHspROxc1wIy o3RYW91grmKJW3WGA8r4+DqCoBMnHPzXSZzsw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=daP2x4GLzegqYAtGzoN/GqQWx/OgbUZpFEmzsIb9AuY=; b=HBjX54aDP/54LJaMRDiuHzPczX2jFPeihUUZ5+nDnaUROOg7yeHjZ6RdwTPKW4AJK8 Wbkv8AGbnnzF+4PPW57M4VLJgNvbHGVgC+Dcgch5B4XOwsAaeJCcV2wLCbxmTn2DoD/G 6RDw+q4CsK3h7n9dQWn1docIms47+u9CoMSLvphVksoYv3PY3qDr6BCqqgyCvicNxExS GaO2BdsRf7oYjEaGioCks8IuKq6/EaJbIKqUSrDsM5lcJWLppSW9nct+uhHSFRXq5SvC F7qYO+SX5ZxGMzuAVXiw7LGiqXDfdcsg9KzbwUF31z4cplUj7Utt3772HtXuAa3UPDtk 6FtQ== X-Gm-Message-State: APjAAAUWqB5Y7Ij2XlDk3g/Ch3vFy0oSIGKtVLh2jBpX7RNj1bLCZ3s+ 6y1u4ZloqVd4azMLbIV9FMr2goV3Rbs= X-Received: by 2002:a05:651c:2046:: with SMTP id t6mr6125805ljo.180.1576176202617; Thu, 12 Dec 2019 10:43:22 -0800 (PST) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id w2sm3463385ljo.61.2019.12.12.10.43.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Dec 2019 10:43:21 -0800 (PST) Received: by mail-lf1-f46.google.com with SMTP id n12so38211lfe.3 for ; Thu, 12 Dec 2019 10:43:21 -0800 (PST) X-Received: by 2002:ac2:4946:: with SMTP id o6mr6694407lfi.170.1576176201157; Thu, 12 Dec 2019 10:43:21 -0800 (PST) MIME-Version: 1.0 References: <87blslei5o.fsf@mpe.ellerman.id.au> <20191206131650.GM2827@hirez.programming.kicks-ass.net> <875zimp0ay.fsf@mpe.ellerman.id.au> <20191212080105.GV2844@hirez.programming.kicks-ass.net> <20191212100756.GA11317@willie-the-truck> <20191212104610.GW2827@hirez.programming.kicks-ass.net> <20191212180634.GA19020@willie-the-truck> In-Reply-To: <20191212180634.GA19020@willie-the-truck> From: Linus Torvalds Date: Thu, 12 Dec 2019 10:43:05 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops)) To: Will Deacon Cc: Peter Zijlstra , Michael Ellerman , dja@axtens.net, Linux Kernel Mailing List , linuxppc-dev@lists.ozlabs.org, Christophe Leroy , linux-arch , Mark Rutland , Segher Boessenkool , Arnd Bergmann , Christian Borntraeger Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 12, 2019 at 10:06 AM Will Deacon wrote: > > I'm currently trying to solve the issue by removing volatile from the bitop > function signatures I really think that's the wrong thing to do. The bitop signature really should be "volatile" (and it should be "const volatile" for test_bit, but I'm not sure anybody cares). Exactly because it's simply valid to say "hey, my data is volatile, but do an atomic test of this bit". So it might be volatile in the caller. Now, I generally frown on actual volatile data structures - because the data structure volatility often depends on _context_. The same data might be volatile in one context (when you do some optimistic test on it without locking), but 100% stable in another (when you do have a lock). So I don't want to see "volatile" on data definitions ("jiffies" being the one traditional exception), but marking things volatile in code (because you know you're working with unlocked data) and then passing them down to various helper functions - including the bitops ones - is quite traditional and accepted. In other words, 'volatile" should be treated the same way "const" is largely treated in C. A pointer to "const" data doesn't mean that the data is read-only, or that it cannot be modified _elsewhere_, it means that within this particular context and this copy of the pointer we promise not to write to it. Similarly, a pointer to "volatile" data doesn't mean that the data might not be stable once you take a lock, for example. So it's ok to have volatile pointers even if the data declaration itself isn't volatile - you're stating something about the context, not something fundamental about the data. And in the context of the bit operations, "volatile" is the correct thing to do. Linus