From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [RFC][PATCH] nfsd regression since delayed fput() Date: Thu, 17 Oct 2013 14:14:57 -0400 Message-ID: <20131017181457.GA6987@fieldses.org> References: <20131016185209.GO13318@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Al Viro , linux-fsdevel To: Linus Torvalds Return-path: Received: from fieldses.org ([174.143.236.118]:42215 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757608Ab3JQSO6 (ORCPT ); Thu, 17 Oct 2013 14:14:58 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Oct 16, 2013 at 09:48:06PM -0700, Linus Torvalds wrote: > On Wed, Oct 16, 2013 at 11:52 AM, Al Viro wrote: > > > > If anybody has better ideas, I'll gladly take those instead - this > > approach feels kludgy ;-/ > > It looks kludgy indeed, but I do like the concept of basically > rate-limiting delayed_fput_work. > > At the same time, I worry that it will cause the same kinds of things > that we discussed for user processes: delayed fput can result in > visible semantic differences (eg silly-renames) if it is delayed past > other operations that care about elevated reference counts. > > Now I hope that people don't nfs-(re)export nfs filesystems, so the > nfs silly-rename isn't necessarily an issue, but I could imagine other > similar things. NFS isn't exportable and there aren't any plans to change that. --b.