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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 E4736C47082 for ; Thu, 3 Jun 2021 17:26:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C63CD6108E for ; Thu, 3 Jun 2021 17:26:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230343AbhFCR2Z (ORCPT ); Thu, 3 Jun 2021 13:28:25 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:44328 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230075AbhFCR2Y (ORCPT ); Thu, 3 Jun 2021 13:28:24 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lor79-000mX8-2C; Thu, 03 Jun 2021 11:26:39 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=email.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lor76-001AUG-Q2; Thu, 03 Jun 2021 11:26:38 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Ian Kent Cc: Greg Kroah-Hartman , Tejun Heo , Eric Sandeen , Fox Chen , Brice Goglin , Al Viro , Rick Lindsley , David Howells , Miklos Szeredi , Marcelo Tosatti , linux-fsdevel , Kernel Mailing List References: <162218354775.34379.5629941272050849549.stgit@web.messagingengine.com> <162218364554.34379.636306635794792903.stgit@web.messagingengine.com> Date: Thu, 03 Jun 2021 12:26:30 -0500 In-Reply-To: <162218364554.34379.636306635794792903.stgit@web.messagingengine.com> (Ian Kent's message of "Fri, 28 May 2021 14:34:05 +0800") Message-ID: <87czt2q2pl.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1lor76-001AUG-Q2;;;mid=<87czt2q2pl.fsf@disp2133>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18V/U3vc+8ginDH12+uNQJ0nulcXisbRXE= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [REPOST PATCH v4 2/5] kernfs: use VFS negative dentry caching X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ian Kent writes: > If there are many lookups for non-existent paths these negative lookups > can lead to a lot of overhead during path walks. > > The VFS allows dentries to be created as negative and hashed, and caches > them so they can be used to reduce the fairly high overhead alloc/free > cycle that occurs during these lookups. > > Signed-off-by: Ian Kent > --- > fs/kernfs/dir.c | 55 +++++++++++++++++++++++++++++++++---------------------- > 1 file changed, 33 insertions(+), 22 deletions(-) > > diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c > index 4c69e2af82dac..5151c712f06f5 100644 > --- a/fs/kernfs/dir.c > +++ b/fs/kernfs/dir.c > @@ -1037,12 +1037,33 @@ static int kernfs_dop_revalidate(struct dentry *dentry, unsigned int flags) > if (flags & LOOKUP_RCU) > return -ECHILD; > > - /* Always perform fresh lookup for negatives */ > - if (d_really_is_negative(dentry)) > - goto out_bad_unlocked; > + mutex_lock(&kernfs_mutex); > > kn = kernfs_dentry_node(dentry); > - mutex_lock(&kernfs_mutex); Why bring kernfs_dentry_node inside the mutex? The inode lock of the parent should protect negative to positive transitions not the kernfs_mutex. So moving the code inside the mutex looks unnecessary and confusing. What NFS does is to check to see if the parent has been modified since the negative dentry was created, can't kernfs do the same and remove the need for taking the lock until the lookup that makes the dentry positive? Doing the lookup twice seems strange. Perhaps this should happen as two changes. One change to enable negative dentries and a second change to optimize d_revalidate of negative dentries. That way the issues could be clearly separated and looked at separately. > + > + /* Negative hashed dentry? */ > + if (!kn) { > + struct kernfs_node *parent; > + > + /* If the kernfs node can be found this is a stale negative > + * hashed dentry so it must be discarded and the lookup redone. > + */ > + parent = kernfs_dentry_node(dentry->d_parent); > + if (parent) { > + const void *ns = NULL; > + > + if (kernfs_ns_enabled(parent)) > + ns = kernfs_info(dentry->d_sb)->ns; > + kn = kernfs_find_ns(parent, dentry->d_name.name, ns); > + if (kn) > + goto out_bad; > + } > + > + /* The kernfs node doesn't exist, leave the dentry negative > + * and return success. > + */ > + goto out; > + } > > /* The kernfs node has been deactivated */ > if (!kernfs_active_read(kn)) > @@ -1060,12 +1081,11 @@ static int kernfs_dop_revalidate(struct dentry *dentry, unsigned int flags) > if (kn->parent && kernfs_ns_enabled(kn->parent) && > kernfs_info(dentry->d_sb)->ns != kn->ns) > goto out_bad; > - > +out: > mutex_unlock(&kernfs_mutex); > return 1; > out_bad: > mutex_unlock(&kernfs_mutex); > -out_bad_unlocked: > return 0; > } > > @@ -1080,33 +1100,24 @@ static struct dentry *kernfs_iop_lookup(struct inode *dir, > struct dentry *ret; > struct kernfs_node *parent = dir->i_private; > struct kernfs_node *kn; > - struct inode *inode; > + struct inode *inode = NULL; > const void *ns = NULL; > > mutex_lock(&kernfs_mutex); > - > if (kernfs_ns_enabled(parent)) > ns = kernfs_info(dir->i_sb)->ns; > > kn = kernfs_find_ns(parent, dentry->d_name.name, ns); > - > - /* no such entry */ > - if (!kn || !kernfs_active(kn)) { > - ret = NULL; > - goto out_unlock; > - } > - > /* attach dentry and inode */ > - inode = kernfs_get_inode(dir->i_sb, kn); > - if (!inode) { > - ret = ERR_PTR(-ENOMEM); > - goto out_unlock; > + if (kn && kernfs_active(kn)) { > + inode = kernfs_get_inode(dir->i_sb, kn); > + if (!inode) > + inode = ERR_PTR(-ENOMEM); > } > - > - /* instantiate and hash dentry */ > + /* instantiate and hash (possibly negative) dentry */ > ret = d_splice_alias(inode, dentry); > - out_unlock: > mutex_unlock(&kernfs_mutex); > + > return ret; > } >