Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 17 May 2021 14:56:59 -0400
From:   "bfields@fieldses.org" <bfields@fieldses.org>
To:     Christoph Hellwig <hch@infradead.org>
Cc:     Trond Myklebust <trondmy@hammerspace.com>,
        "nickhuang@synology.com" <nickhuang@synology.com>,
        "chuck.lever@oracle.com" <chuck.lever@oracle.com>,
        "robbieko@synology.com" <robbieko@synology.com>,
        "bingjingc@synology.com" <bingjingc@synology.com>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] nfsd: Prevent truncation of an unlinked inode from
 blocking access to its directory
Message-ID: <20210517185659.GA4216@fieldses.org>
References: <20210514035829.5230-1-nickhuang@synology.com>
 <00195ec8bf1752306f549540eed74c3938c5e312.camel@hammerspace.com>
 <YJ9yD1S6Yl2m0gOO@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YJ9yD1S6Yl2m0gOO@infradead.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Sat, May 15, 2021 at 08:02:39AM +0100, Christoph Hellwig wrote:
> On Fri, May 14, 2021 at 03:46:57PM +0000, Trond Myklebust wrote:
> > Why leave the commit_metadata() call under the lock? If you're
> > concerned about latency, then it makes more sense to call fh_unlock()
> > before flushing those metadata updates to disk.
> 
> Also I'm not sure why the extra inode reference is needed.  What speaks
> against just moving the dput out of the locked section?

I don't know.  Do you know why do_unlinkat() is doing the same thing?

--b.