From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops)) Date: Mon, 16 Dec 2019 12:47:24 +0100 Message-ID: <20191216114724.GL2844@hirez.programming.kicks-ass.net> References: <20191212080105.GV2844@hirez.programming.kicks-ass.net> <20191212100756.GA11317@willie-the-truck> <20191212104610.GW2827@hirez.programming.kicks-ass.net> <20191212180634.GA19020@willie-the-truck> <20191212193401.GB19020@willie-the-truck> <20191213144359.GA3826@willie-the-truck> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20191213144359.GA3826@willie-the-truck> Sender: linux-kernel-owner@vger.kernel.org To: Will Deacon Cc: Arnd Bergmann , Linus Torvalds , Michael Ellerman , Daniel Axtens , Linux Kernel Mailing List , linuxppc-dev , Christophe Leroy , linux-arch , Mark Rutland , Segher Boessenkool , Christian Borntraeger List-Id: linux-arch.vger.kernel.org On Mon, Dec 16, 2019 at 10:28:06AM +0000, Will Deacon wrote: > However, enabling this for 32-bit ARM is total carnage; as Linus mentioned, > a whole bunch of code appears to be relying on atomic 64-bit access of > READ_ONCE(); the perf ring buffer, io_uring, the scheduler, pm_runtime, > cpuidle, ... :( > > Unfortunately, at least some of these *do* look like bugs, but I can't see > how we can fix them, not least because the first two are user ABI afaict. It > may also be that in practice we get 2x32-bit stores, and that works out fine > when storing a 32-bit virtual address. I'm not sure what (if anything) the > compiler guarantees in these cases. Perf does indeed have a (known) problem here for the head/tail values. Last time we looked at that nobody could really come up with a sane solution that wouldn't break something. I'll try and dig out that thread. Perhaps casting the value to 'unsigned long' internally might work, I forgot the details. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from merlin.infradead.org ([205.233.59.134]:38902 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727241AbfLPLr5 (ORCPT ); Mon, 16 Dec 2019 06:47:57 -0500 Date: Mon, 16 Dec 2019 12:47:24 +0100 From: Peter Zijlstra 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: <20191216114724.GL2844@hirez.programming.kicks-ass.net> References: <20191212080105.GV2844@hirez.programming.kicks-ass.net> <20191212100756.GA11317@willie-the-truck> <20191212104610.GW2827@hirez.programming.kicks-ass.net> <20191212180634.GA19020@willie-the-truck> <20191212193401.GB19020@willie-the-truck> <20191213144359.GA3826@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191213144359.GA3826@willie-the-truck> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Will Deacon Cc: Arnd Bergmann , Linus Torvalds , Michael Ellerman , Daniel Axtens , Linux Kernel Mailing List , linuxppc-dev , Christophe Leroy , linux-arch , Mark Rutland , Segher Boessenkool , Christian Borntraeger Message-ID: <20191216114724.vHFRcdOUak3swS4jHzzN3y51-syIMwkt__zPi64VhQM@z> On Mon, Dec 16, 2019 at 10:28:06AM +0000, Will Deacon wrote: > However, enabling this for 32-bit ARM is total carnage; as Linus mentioned, > a whole bunch of code appears to be relying on atomic 64-bit access of > READ_ONCE(); the perf ring buffer, io_uring, the scheduler, pm_runtime, > cpuidle, ... :( > > Unfortunately, at least some of these *do* look like bugs, but I can't see > how we can fix them, not least because the first two are user ABI afaict. It > may also be that in practice we get 2x32-bit stores, and that works out fine > when storing a 32-bit virtual address. I'm not sure what (if anything) the > compiler guarantees in these cases. Perf does indeed have a (known) problem here for the head/tail values. Last time we looked at that nobody could really come up with a sane solution that wouldn't break something. I'll try and dig out that thread. Perhaps casting the value to 'unsigned long' internally might work, I forgot the details.