Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755603AbcKYSqk (ORCPT ); Fri, 25 Nov 2016 13:46:40 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:46323 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755439AbcKYSqh (ORCPT ); Fri, 25 Nov 2016 13:46:37 -0500 Subject: Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE() To: Mark Rutland References: <20161125112203.GA26611@leverpostej> <32dfca07-59f3-b75a-3154-cf6b6c8538f0@de.ibm.com> <20161125122356.GB26611@leverpostej> <20161125124044.GN3092@twins.programming.kicks-ass.net> <20161125124404.GI3174@twins.programming.kicks-ass.net> <20161125145512.GA4014@Boquns-MacBook-Pro.local> <20161125161004.GA30181@leverpostej> <20161125161709.GQ3092@twins.programming.kicks-ass.net> <20161125172624.GA30811@leverpostej> Cc: Peter Zijlstra , Dmitry Vyukov , Boqun Feng , "Michael S. Tsirkin" , LKML , Davidlohr Bueso , dbueso@suse.de, jasowang@redhat.com, KVM list , netdev , Paul McKenney , virtualization@lists.linux-foundation.org, Linus Torvalds From: Christian Borntraeger Date: Fri, 25 Nov 2016 19:46:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161125172624.GA30811@leverpostej> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16112518-0028-0000-0000-00000257EABF X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16112518-0029-0000-0000-0000215C3081 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-25_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611250320 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1809 Lines: 46 On 11/25/2016 06:28 PM, Mark Rutland wrote: > On Fri, Nov 25, 2016 at 05:49:45PM +0100, Christian Borntraeger wrote: >> On 11/25/2016 05:17 PM, Peter Zijlstra wrote: >>> On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote: >>>> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: >>> >>>>> What are use cases for such primitive that won't be OK with "read once >>>>> _and_ atomically"? >>>> >>>> I have none to hand. >>> >>> Whatever triggers the __builtin_memcpy() paths, and even the size==8 >>> paths on 32bit. >>> >>> You could put a WARN in there to easily find them. >> >> There were several cases that I found during writing the *ONCE stuff. >> For example there are some 32bit ppc variants with 64bit PTEs. Some for >> others (I think sparc). > > We have similar on 32-bit ARM w/ LPAE. LPAE implies that a naturally > aligned 64-bit access is single-copy atomic, which is what makes that > ok. > >> And the mm/ code is perfectly fine with these PTE accesses being done >> NOT atomic. > > That strikes me as surprising. Is there some mutual exclusion that > prevents writes from occuring wherever a READ_ONCE() happens to a PTE? See for example mm/memory.c handle_pte_fault. ---snip---- /* * some architectures can have larger ptes than wordsize, * e.g.ppc44x-defconfig has CONFIG_PTE_64BIT=y and * CONFIG_32BIT=y, so READ_ONCE or ACCESS_ONCE cannot guarantee * atomic accesses. The code below just needs a consistent * view for the ifs and we later double check anyway with the * ptl lock held. So here a barrier will do. */ ---snip--- The trick is that the code only does a specific check, but all other accesses are under the pte lock.