Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1133341ybl; Thu, 12 Dec 2019 10:07:42 -0800 (PST) X-Google-Smtp-Source: APXvYqwS7tP1xa6psX5buOJ95rPB3A+aFmtEFiap5Fc4PAH530pZ9jEI/Q6hfCUM2/irqjCwVb1j X-Received: by 2002:a9d:73c8:: with SMTP id m8mr9876905otk.34.1576174062528; Thu, 12 Dec 2019 10:07:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576174062; cv=none; d=google.com; s=arc-20160816; b=lVc/uw3s+3fN7PL5m5QGQpHvdP7SY26/gLmnoITdh+7y/KZvXlO8uz2512VwrIjLQK 3PKeZIVJCf9bxxNxOuQffMIV3Mo29mV2UKB0Nmzed/oMCehktt7OPDioMv4ZQk9HEM/6 CE9YbAFiOW/q+quSfxN78Y8yp//ADNUL0Tc8TD6JApPeTC1+4wNpzvLSLAzJdhw3PpSN Aje9HzNVHv8EgSvPALT/3W/MyCfZfoSqi4O1Mi88dbWW9tNaxtqUMBEkeTzoO53ezUHP 5mz1klrEDWIotqFR/H+fC5xzwnj1K7e2GOytFccHThOvbt+LjilkERUEe/Y9NAkfMP1r 2+rQ== 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; bh=JQP3C81m0u95K7r9+gRAuhkpYFG/X39AB25fW6jfS7M=; b=VZsNbGZP/+2NgoXfrD6Xp2FEJ9HWndH94IXNQbU/x61afZo5BaNuQNZ/BfmbWcuvF9 pXAFscjbU2y95pv194e/Of3BFmU6nlS74l0N7LYJLN4oQGPSuISobpl27sNG85BAoZzA mZvy1YbfgmBjBPSLpQJv/sLklZejabk0v5NrP0wJO1zZKG5Ibw4sNroumD349x6vs4b/ AnGcReREEfM/Eemdv8BbbLN4PG5x/vvDdlHuBOJs5kiHX83KqcTN66/eo6J6PbzJS5hk JHyWC0L1N++QcLwFNx0pv8987sRda+2fzc0mrZuvaE5t61JjP/2gyGlrxR/gPXzJ3pCb dCRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ONkagQPl; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p26si3727987oto.240.2019.12.12.10.07.24; Thu, 12 Dec 2019 10:07:42 -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=@kernel.org header.s=default header.b=ONkagQPl; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730235AbfLLSGl (ORCPT + 99 others); Thu, 12 Dec 2019 13:06:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:54212 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730159AbfLLSGl (ORCPT ); Thu, 12 Dec 2019 13:06:41 -0500 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D8834214AF; Thu, 12 Dec 2019 18:06:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576174000; bh=QbYFPcyUbQkcB6fG8/43kB0aA3LyHLLV1x1hYhirNx0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ONkagQPlYuBVQGWVNonUeKbx415r1LL+qzkuQsGkw33plWbHk8Y/45w/+OuUwoXCm a5KjjB7xE5Vn1z36KKIiaXEYfj4X67Sr4VZj4DfY1fCjTA3atFezHXphkDnvLkYhOh HUgLBzevlZk67TF8LP5CzctiU32bk+HDC9azTeo4= Date: Thu, 12 Dec 2019 18:06:35 +0000 From: Will Deacon To: Linus Torvalds 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 Subject: Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops)) Message-ID: <20191212180634.GA19020@willie-the-truck> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 09:41:32AM -0800, Linus Torvalds wrote: > On Thu, Dec 12, 2019 at 2:46 AM Peter Zijlstra wrote: > > > > +#ifdef GCC_VERSION < 40800 > > Where does that 4.8 version check come from, and why? > > Yeah, I know, but this really wants a comment. Sadly it looks like gcc > bugzilla is down, so > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 > > currently gives an "Internal Server Error" for me. > > [ Delete the horrid code we have because of gcc bugs ] > > > +#else /* GCC_VERSION < 40800 */ > > + > > +#define READ_ONCE_NOCHECK(x) \ > > +({ \ > > + typeof(x) __x = *(volatile typeof(x))&(x); \ > > I think we can/should just do this unconditionally if it helps th eissue. I'm currently trying to solve the issue by removing volatile from the bitop function signatures, but it's grotty because there are quite a few callers to fix up. I'm still trying to do it, because removing volatile fields from structurs is generally a "good thing", but I'd be keen to simplify READ_ONCE() as you suggest regardless. > Maybe add a warning about how gcc < 4.8 might mis-compile the kernel - > those versions are getting close to being unacceptable for kernel > builds anyway. > > We could also look at being stricter for the normal READ/WRITE_ONCE(), > and require that they are > > (a) regular integer types > > (b) fit in an atomic word > > We actually did (b) for a while, until we noticed that we do it on > loff_t's etc and relaxed the rules. But maybe we could have a > "non-atomic" version of READ/WRITE_ONCE() that is used for the > questionable cases? That makes a lot of sense to me, and it would allow us to use compiletime_assert_atomic_type() as we do for the acquire/release accessors. Will