From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Tue, 16 Aug 2016 11:45:37 +0100 Subject: Problem with atomic accesses in pstore on some ARM CPUs In-Reply-To: <8f0c9ced-cdc3-ab9b-caee-06fe85e6c1e7@arm.com> References: <8f0c9ced-cdc3-ab9b-caee-06fe85e6c1e7@arm.com> Message-ID: <20160816104537.GB27088@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Aug 16, 2016 at 11:32:04AM +0100, Robin Murphy wrote: > On 16/08/16 00:19, Guenter Roeck wrote: > > we are having a problem with atomic accesses in pstore on some ARM > > CPUs (specifically rk3288 and rk3399). With those chips, atomic > > accesses fail with both pgprot_noncached and pgprot_writecombine > > memory. Atomic accesses do work when selecting PAGE_KERNEL protection. > > What's the pstore backed by? I'm guessing it's not normal DRAM. Regardless, pgprot_noncached and pgprot_writecombine map to Device-nGnRnE and Normal-non-cacheable respectively, and so it's IMP DEP whether or not exclusives will work there. > > Debugging on rk3399 shows the following crash. > > > > [ 0.912669] Bad mode in Error handler detected, code 0xbf000002 -- SError > > [ 0.920140] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 4.4.14 #389 > > [ 0.926838] Hardware name: Google Kevin (DT) > > [ 0.931533] task: ffffffc0edfe0000 ti: ffffffc0edf7c000 task.ti: > > ffffffc0edf 7c000 > > [ 0.939780] PC is at __ll_sc___cmpxchg_case_mb_4+0x2c/0x5c > > [ 0.945811] LR is at 0x1 > > > > The "solution" for this problem in various Chrome OS releases is to > > disable atomic accesses in pstore entirely, which seems to be a bit > > brute-force. Question is what a proper upstream-acceptable solution Why do you require atomics to the pstore? If you need to serialise updates from coherent observers (e.g. CPUs), is it acceptable to use a lock in normal memory instead? Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753296AbcHPKp3 (ORCPT ); Tue, 16 Aug 2016 06:45:29 -0400 Received: from foss.arm.com ([217.140.101.70]:46158 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751532AbcHPKp2 (ORCPT ); Tue, 16 Aug 2016 06:45:28 -0400 Date: Tue, 16 Aug 2016 11:45:37 +0100 From: Will Deacon To: Robin Murphy Cc: Guenter Roeck , Kees Cook , Jeffy Chen , Colin Cross , Tony Luck , Douglas Anderson , linux-kernel , linux-arm-kernel@lists.infradead.org Subject: Re: Problem with atomic accesses in pstore on some ARM CPUs Message-ID: <20160816104537.GB27088@arm.com> References: <8f0c9ced-cdc3-ab9b-caee-06fe85e6c1e7@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f0c9ced-cdc3-ab9b-caee-06fe85e6c1e7@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 16, 2016 at 11:32:04AM +0100, Robin Murphy wrote: > On 16/08/16 00:19, Guenter Roeck wrote: > > we are having a problem with atomic accesses in pstore on some ARM > > CPUs (specifically rk3288 and rk3399). With those chips, atomic > > accesses fail with both pgprot_noncached and pgprot_writecombine > > memory. Atomic accesses do work when selecting PAGE_KERNEL protection. > > What's the pstore backed by? I'm guessing it's not normal DRAM. Regardless, pgprot_noncached and pgprot_writecombine map to Device-nGnRnE and Normal-non-cacheable respectively, and so it's IMP DEP whether or not exclusives will work there. > > Debugging on rk3399 shows the following crash. > > > > [ 0.912669] Bad mode in Error handler detected, code 0xbf000002 -- SError > > [ 0.920140] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 4.4.14 #389 > > [ 0.926838] Hardware name: Google Kevin (DT) > > [ 0.931533] task: ffffffc0edfe0000 ti: ffffffc0edf7c000 task.ti: > > ffffffc0edf 7c000 > > [ 0.939780] PC is at __ll_sc___cmpxchg_case_mb_4+0x2c/0x5c > > [ 0.945811] LR is at 0x1 > > > > The "solution" for this problem in various Chrome OS releases is to > > disable atomic accesses in pstore entirely, which seems to be a bit > > brute-force. Question is what a proper upstream-acceptable solution Why do you require atomics to the pstore? If you need to serialise updates from coherent observers (e.g. CPUs), is it acceptable to use a lock in normal memory instead? Will