From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55819C43381 for ; Sun, 17 Mar 2019 04:23:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 191BF20872 for ; Sun, 17 Mar 2019 04:23:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b="Td5DWskT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726058AbfCQEXT (ORCPT ); Sun, 17 Mar 2019 00:23:19 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:53354 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725946AbfCQEXT (ORCPT ); Sun, 17 Mar 2019 00:23:19 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 94DD28EE0C9; Sat, 16 Mar 2019 21:23:18 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYYET199fKrw; Sat, 16 Mar 2019 21:23:18 -0700 (PDT) Received: from [153.66.254.194] (unknown [50.35.68.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id E92578EE0C7; Sat, 16 Mar 2019 21:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1552796598; bh=W5YksEOgCyJ++H53fdxgx56fyHhw1aicz98Cqvf9s0I=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Td5DWskTvBvNwxLzHAVMDtVeLsLqDXUUarYxdvEMlxUp90QSFRfaq+oe6XgGV5V2e lOJXUBeVU3fzM7gTcaF79bYQxyVv4HBloE7wl8i1CFw8hQc41SRJV0JRJH8QCw4XIN 2VvaPVtcn7C8wkzuGgHPSq38gQsD5TuZNmI90NAc= Message-ID: <1552796596.6551.17.camel@HansenPartnership.com> Subject: Re: dcache locking question From: James Bottomley To: Al Viro Cc: paulmck@linux.ibm.com, Eric Biggers , "Tobin C. Harding" , linux-fsdevel@vger.kernel.org Date: Sat, 16 Mar 2019 21:23:16 -0700 In-Reply-To: <20190317030634.GG2217@ZenIV.linux.org.uk> References: <20190314225632.GB15813@eros.localdomain> <20190314231939.GA17269@eros.localdomain> <20190315015021.GU2217@ZenIV.linux.org.uk> <20190315173819.GB77949@gmail.com> <20190315185455.GA2217@ZenIV.linux.org.uk> <20190316223128.GV4102@linux.ibm.com> <20190317001840.GF2217@ZenIV.linux.org.uk> <20190317005005.GY4102@linux.ibm.com> <1552789220.6551.13.camel@HansenPartnership.com> <20190317030634.GG2217@ZenIV.linux.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Sun, 2019-03-17 at 03:06 +0000, Al Viro wrote: > On Sat, Mar 16, 2019 at 07:20:20PM -0700, James Bottomley wrote: > > On Sat, 2019-03-16 at 17:50 -0700, Paul E. McKenney wrote: > > [...] > > > I -have- seen stores of constant values be torn, but not stores > > > of runtime-variable values and not loads. Still, such tearing is > > > permitted, and including the READ_ONCE() is making it easier for > > > things like thread sanitizers. In addition, the READ_ONCE() > > > makes it clear that the value being loaded is unstable, which can > > > be useful documentation. > > > > Um, just so I'm clear, because this assumption permeates all our > > code: load or store tearing can never occur if we're doing load or > > store of a 32 bit value which is naturally aligned. Where > > naturally aligned is within the gift of the CPU to determine but > > which the compiler or kernel will always ensure for us unless we > > pack the structure or deliberately misalign the allocation. > > Wait a sec; are there any 64bit architectures where the same is not > guaranteed for dereferencing properly aligned void **? Yes, naturally alligned void * dereference shouldn't tear either. I was just using 32 bit as my example because 64 bit accesses will tear on 32 bit architectures but 64 bit naturally aligned accesses shouldn't tear on 64 bit architectures. However, since we can't guarantee the 64 bitness of the architecture 32 bit or void * is our gold standard for not tearing. James > If that's the case, I can think of quite a few places that are rather > dubious, and I don't see how READ_ONCE() could help in those - e.g. > if an architecture only has 32bit loads, rcu list traversals are > not going to be doable without one hell of an extra headache. >