Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp5751438ybg; Tue, 22 Oct 2019 07:53:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqxOmRphvCFBJFbflVjCioNQJD0X5gx2WT7sJ4MeZsFASLhDQgqrW7iSXakWmzvYU+xOuM5k X-Received: by 2002:a17:906:7e50:: with SMTP id z16mr16626201ejr.130.1571755988576; Tue, 22 Oct 2019 07:53:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571755988; cv=none; d=google.com; s=arc-20160816; b=seKr9hO42ltqQVK2+Y1Xnyq6aMDwgNz1YLGs3GhzFSTd7WUtsd+YraGQd1TT3xCWGu ryGHXJpixaX09QzIIoU49FZUmDb1bpmvUOgsbQcBljpKdAjqdsrwp0Ndvp75jFqPr0ou 9EgjynMacyZdr2uXLF3wNwpzo9uZK2ZGG77PrkoycqxfRJYv73sFpoAavADj6RaoQx9A w+XgpHpr6cXW+oH9MFDpxKmOyvhWalGg3U00FwrhIlidSQWe2F7eqcA66iVHM/y7SlUJ PWsvMXjBQ+R2AYeSAGhnvcLYA7fPWSyB6ND/JP522I4+sC4G16DPBU3moj5FRMlmTOEx GXZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=h6+6KLVyWqrpSYA3/Rgjh4TGqUppP/UdbeOWLRDdr28=; b=Kvs60JbZxxvqVUgaNwW4gUTI1vhFyGRdxWYC0xzsk/094j9sMNoYhnIWmrtwquRUdW v8sxbLeduRWrc3bIBmuCaxG4Y3mbGJapLl0prWZar2BFA6am+0kbk1tRFlWHtzL3OaUQ IVVQlg4j+wuKJ/idSGc9lRuym2oA7kfVKC4i1U+oz+P7iFx5OjOA1tcBq+iWWuF+WqOx DpADiG+aPHhYDMsNGO4ChWLdElxSgnY3YjqNtI8yAsT4w/B/Hu40Ae494mntPNYVm7Il tdCM+XgbrJVbXMY14NxtUKuiWGC3Iyi+ogkIQA7c3LniNLlC05qX1lEfw5fH2Iyc7Seg biQA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g2si1258375edn.415.2019.10.22.07.52.44; Tue, 22 Oct 2019 07:53:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732056AbfJVOuz (ORCPT + 99 others); Tue, 22 Oct 2019 10:50:55 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:38950 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727531AbfJVOuz (ORCPT ); Tue, 22 Oct 2019 10:50:55 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1iMvUr-0000Jf-Jb; Tue, 22 Oct 2019 14:50:53 +0000 Date: Tue, 22 Oct 2019 15:50:53 +0100 From: Al Viro To: Ritesh Harjani Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, wugyuan@cn.ibm.com, jlayton@kernel.org, hsiangkao@aol.com, Jan Kara , Linus Torvalds Subject: Re: [PATCH RESEND 1/1] vfs: Really check for inode ptr in lookup_fast Message-ID: <20191022145053.GY26530@ZenIV.linux.org.uk> References: <20190927044243.18856-1-riteshh@linux.ibm.com> <20191015040730.6A84742047@d06av24.portsmouth.uk.ibm.com> <20191022133855.B1B4752050@d06av21.portsmouth.uk.ibm.com> <20191022143736.GX26530@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191022143736.GX26530@ZenIV.linux.org.uk> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 22, 2019 at 03:37:36PM +0100, Al Viro wrote: > I'm somewhat tempted to make __d_set_inode_and_type() do smp_store_release() > for setting ->d_flags and __d_entry_type() - smp_load_acquire(); that would > be pretty much free for x86 (as well as sparc, s390 and itanic) and reasonably > cheap on ppc and arm64. How badly would e.g. SMP arm suffer from the below > (completely untested)? PS: if we really go that way, we'd probably want __d_is_negative(), to be used only under ->d_lock or with ->d_seq validation. d_is_negative() callers in fs/dcache.c (all under ->d_lock) as well as the RCU-side one in lookup_fast() (->d_seq validated) would you that. Another fun place is do_unlinkat() - there we want to reorder inode = dentry->d_inode; if (d_is_negative(dentry)) goto slashes; As it were, the same race here can lead to unbalanced iput(), if you hit the window just right.