From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755809AbcHVVEO (ORCPT ); Mon, 22 Aug 2016 17:04:14 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:59632 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753716AbcHVVEN (ORCPT ); Mon, 22 Aug 2016 17:04:13 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Mark Rutland , Guenter Roeck , Tony Luck , Kees Cook , Jeffy Chen , Will Deacon , linux-kernel , Douglas Anderson , Colin Cross , Robin Murphy Subject: Re: Problem with atomic accesses in pstore on some ARM CPUs Date: Mon, 22 Aug 2016 23:03:02 +0200 Message-ID: <11973430.JhDduGIT84@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-31-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160815221518.GD1120@svinekod> References: <20160815221518.GD1120@svinekod> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:3Xp3aQAdbAQmJG0/nniFFtOkMD8mgRHWa+vAuhsgSXSXSwAWhqi v6lE2O83x0igeeHmEijrKis7NvoQgANifDbIMBR52e6KdN5LxhfkMjrALGk3QzstQcjXBll HldanwFXc2Kr/hR5u/SuxZwtO+9iSbUsRNXx57lrUs1qf1pjjn/x3oHIpzE02iMNuaYnay2 jjHbEEnAInO4vXLeNvYcQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:1e+R+R34/08=:RvrjUaWs3Piw4HkTlOV+Ag 45CzysoPO98kEHzu2nLQelO+Eg8YQ32J5WbUvh9MPnNzZu//Z1N3h8d4lZLTItg8c+dBGrrp4 XtChUIxNzoLvZ0PYaU1F2QijfObnsi1wrjXL8txKIFqAc5DkyqGTf45TAKCNYYFNAGlJh9yhC KxozWXmholhzIGJ5WnYnNiS5jWFHTEycVvAoTGACD0R2EMKQUMjDJstuYTrzacd0yuuThP9lH mlx/hzBy8Q7Oj84CDN0hJU4AyGT5iEqTO9czsMnq5jr8cIJwgaCYMyKT7e1aRKcsWP62F5oGV QaMbUlrsCHi8Fu73hrodwSSk8G/bo7BvJZdhu8hOcRnckbyPhGWKZ4GqV9SkArfD2q06RURPh 0gK8eNqwX49U94WS7WxrDE0w708LXaMjjdGoYPzjITQ5C4LTIREepgOtS/TcOiFknB6k6FPZp 6Yzw1IHVLHphGZ4XHm/3Y7EUPR5EzCFdG9Mio4BubiXxb8gCBOFu322dBqbLixxQLUKkddCOD qjz7sr5w71o+fBP8kW5aPKDiJZLd3cRdtCHRDbC3VVg74KbucsUtoBMQc/AK65Ajqa6ma1lK2 Xmr2DqKm/7AG5+mNyQ4SlengisTEdztTaIH4D9XSIKHo+f8IKApkJQXLtMn0NzLWYMbbzw4RH ujTfBeEdVwD4XTqS/ptU5m9QR5OZ4BlkXW6sFy0AbGhspJ99uW3+t1ngPKrC8+Iilbp074CFM 5plSn60IXnu4NbLI Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, August 15, 2016 11:15:18 PM CEST Mark Rutland wrote: > On Tue, Aug 16, 2016 at 08:02:53AM -0700, Guenter Roeck wrote: > > On Tue, Aug 16, 2016 at 6:21 AM, Will Deacon wrote: > > > On Tue, Aug 16, 2016 at 06:14:53AM -0700, Guenter Roeck wrote: > > >> On Tue, Aug 16, 2016 at 3:32 AM, 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. > > >> > > > >> > > >> it is normal DRAM. > > > > > > In which case, why does it need to be mapped with weird attributes? > > > Is there an alias in the linear map you can use? > > > > > > > I don't really _want_ to do anything besides using pstore as-is, or, > > in other words, to have the upstream kernel work with the affected > > systems. > > > > The current pstore code runs the following code for memory with > > pfn_valid() = true. > > > > if (memtype) > > prot = pgprot_noncached(PAGE_KERNEL); > > else > > prot = pgprot_writecombine(PAGE_KERNEL); > > ... > > vaddr = vmap(pages, page_count, VM_MAP, prot); > > > > It then uses the memory pointed to by vaddr for atomic operations. > > This means that the generic ramoops / pstore code is making non-portable > assumptions about memory types. > > So _something_ has to happen to that code. If we have both a cacheable and a noncacheable mapping for the same DRAM area, things get even worse across many architectures. IIRC PowerPC will trigger a checkstop if it encounters a valid cache line for a noncacheable mapping. If there is only one mapping, this is not a problem, but we probably want to avoid having a write-back cache here, in case something serious goes wrong and all the cache is invalidated but the pstore is used for post-mortem analysis. Arnd