Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp768476yba; Thu, 18 Apr 2019 09:13:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqw6Iu/QnOuwDUYrYcASJJk/oDFETVsktTKh6qJSiH+8wf5DWj/D7LcKDBrJb7aMd+Zt7eW6 X-Received: by 2002:a65:4589:: with SMTP id o9mr72888502pgq.381.1555603990015; Thu, 18 Apr 2019 09:13:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555603990; cv=none; d=google.com; s=arc-20160816; b=X+dLukxI/NJ3nEtYrHHkia9aDJt3LGkZf5UOQMHaZT9BViur1TH8s60bkYGfRVl2ci Ql0ZFgGilZL4/84BSZCVuYGYUnd9V/nntdmaZPvvx4shUmr6JlycbyS/FmzTMbE7XP1u smhCUutJTaw7hLKJNt07wwDDY6WSoPIDbeT5fDmANu0e4WLDImP/qhLNWHVp59xc0Cjg XgAWHULo6adh1N299ARUH4sz+Xf8zVKtxRQpOqEqEInKKDzPm5uAJMtEIXeeyeNV6OGa /Wsol94MoV/PdSr5+BxY1WAS/H5+C198oW8xoXkr6gq/pRCc/FbxAX9/151xUtR3HrQF qwTQ== 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:dkim-signature; bh=oS7KgJXOC9kOF+iDz/8huWGUUglCJRqvLpTJU2MsyVU=; b=MjcyYqPSuKxt870nyb8EzCD/12l4nLofAcN2nmx6KcZ/pawDeerjDFjzrsbmY8yyVc CGGwKF9GjgKFeTISfYBY6ssyE2QfDr/GfsBl3VR3kC118L0KWpazgrSuHp38BKPj1mFL cZZQQLCqMF8C21Y+pCkAwHi3B4pNOedA2FrQ7JaLAnAVCedTI5oq7X9f+DoQpQguCmdy X/bhY6azydXfxkrFPdeoZ/aISuGpabBWT4x6JVAcCdLTXgymxsz+2aGGd6QC8zs47+Sl 94HWJMHjZYeycYQlUNvLhh0sqW8lpRINgRKGzyYTkTNabdpCDOGx1Z2LvG92MHvUB9v6 tXYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=ELfYDLCE; 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 f9si2523358plo.101.2019.04.18.09.12.54; Thu, 18 Apr 2019 09:13:10 -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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=ELfYDLCE; 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 S2389649AbfDRQLr (ORCPT + 99 others); Thu, 18 Apr 2019 12:11:47 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:57906 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388775AbfDRQLq (ORCPT ); Thu, 18 Apr 2019 12:11:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oS7KgJXOC9kOF+iDz/8huWGUUglCJRqvLpTJU2MsyVU=; b=ELfYDLCEyb/KICbhZANNZhLB+ 8QPRi4lVsBs+AR19o09ExyFn0h7kEZJKobvAcc96332PlpAgOqsh1/5i4Wn5227S3HqA4sXekmvGD ZHGc7BpxCZsUoyHLS7L6YeFczgy94u+haNlnLIUQTZlKptRdGlXAV1ASO2I4WZTCejqA0oOFQgctn btz1A+QfyKZdhL8iz9OpItjtU8UJaR4bjdVErdYQ4zXgxzO9MPnSx7lwmp+NK0r03vyrYK5LDqjic wwuRWD6d57VhJWKjF3Za+e2X+Q2IGkQwjpwkB0qB5UO8VdhKzABjlhEyJiqe5Xe0F011EuooZ3K2U PcvUGXKyQ==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1hH9cG-0001gW-Gd; Thu, 18 Apr 2019 16:10:24 +0000 Date: Thu, 18 Apr 2019 09:10:24 -0700 From: Matthew Wilcox To: David Howells Cc: viro@zeniv.linux.org.uk, Jan Harkes , coda@cs.cmu.edu, codalist@coda.cs.cmu.edu, linux-afs@lists.infradead.org, linux-ext4@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/6] vfs, coda: Fix the lack of locking in FID replacement inode rehashing Message-ID: <20190418161024.GG7751@bombadil.infradead.org> References: <155559635133.21702.4737487773869377967.stgit@warthog.procyon.org.uk> <155559636704.21702.4538723150377303298.stgit@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155559636704.21702.4538723150377303298.stgit@warthog.procyon.org.uk> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 18, 2019 at 03:06:07PM +0100, David Howells wrote: > Fix this by moving the core part of the code to fs/inode.c and providing it > with a set() function akin to iget5(). We can then take the inode cache > lock whilst performing the move. > @@ -123,6 +132,8 @@ void coda_replace_fid(struct inode *inode, struct CodaFid *oldfid, > > BUG_ON(!coda_fideq(&cii->c_fid, oldfid)); > > + rehash_inode(inode, hash, coda_reset_inode, newfid); > + > /* replace fid and rehash inode */ > /* XXX we probably need to hold some lock here! */ > remove_inode_hash(inode); Don't you also need to delete the remove_inode_hash() and __insert_inode_hash() calls?