Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp567238pxj; Fri, 11 Jun 2021 06:13:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwC/q/0f2UYu0nkRtihIssO4vtffr/+EUYg0WuxZqIPTXSRYE5IJAhEGelOgvrgYTV4bNzD X-Received: by 2002:a17:906:6dc5:: with SMTP id j5mr3580043ejt.364.1623417213705; Fri, 11 Jun 2021 06:13:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623417213; cv=none; d=google.com; s=arc-20160816; b=t1JqtxictdbDUortU+Cg0LyXkO/aHdaXzc7Sjk28LUY4IttGXQ2DcFQTEFoADeen+v 1MoxbK0zLaiX2DF4/vm4LS8M0sKIhn+uRVy1Ph9obCM7pLwAd+eszpfo+5jgOvy6QCw3 9ygV+jyvtDG9eywA13gcyreyUGrlBof4k4qf4oMvPPwsjgNa8NG1dPL4SCqG+9OA7juh x0QpAuErCbeRMULGmkeK3JlS/HeXV/NcFkVV6A8nvlpZ71JRxaXd07AW0Z+XVLTcqgnd CwraoThRHtWxIqqnrP0x+EayYBki6t+WyZZd9m+db4l3jdybR9CFXGnRlNb3t7ZPRWJJ fQtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=P+b8MfztkEwhNTnGkFZQY+Dgwg11CERi+x6bGLVrEkM=; b=h/+YTuXDWTRaYNhMFXw9w+SYIroL4PVDdE7ew2JxmDUFCfiAQIN7g8YibjAdcDpJ6K zSDPef2+VOMwaqvmY11gKuN33EWMlqcu9tYrXgO29jZcBReP9AGY2rhScyB9JCjaUnYK aXRxWIF51fAYwtJL3OZjO0Lt0K8sKzOG55mqQveLFwESx+viFefSwUS/f2pxfGMoK4EK HYBqLsBTJusqQnZz89nCZwSWhpdlB13YEloUVdLdebTHNNT9amOaO3GUzZg3CL0qMunq 6JJfdJ3+UWdgLsDlCJVwsO6O3hFH1spAckwJFSxN1P42v1qSDZgNXz0Yp9aKD/hJSM8d Qdzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=eEeYxrv2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y18si4965352edr.488.2021.06.11.06.13.11; Fri, 11 Jun 2021 06:13:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=eEeYxrv2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231634AbhFKNNO (ORCPT + 99 others); Fri, 11 Jun 2021 09:13:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:33434 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230382AbhFKNNO (ORCPT ); Fri, 11 Jun 2021 09:13:14 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9C642613DF; Fri, 11 Jun 2021 13:11:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1623417076; bh=HjD6ATEHpIBvWwW2dFdI6JGuiSnbs0d11W1EQk87HK4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eEeYxrv2qE/H4pN9gcdAaIU4RGw4zLIA4uJlrOUd/sXlOnYfWL/q3+e+5PGQgxKPa 1gjo1t2fUXvd5n7YWrPERdSj0Oan+en01fRDBTVe3/EXLRChsqFYinN5ZyFr0gnp8r fjmKmoEX6ZqT7IfTCsblEK0JEsV9uIaOJ4VHyt9c= Date: Fri, 11 Jun 2021 15:11:13 +0200 From: Greg Kroah-Hartman To: Ian Kent Cc: Miklos Szeredi , Tejun Heo , Eric Sandeen , Fox Chen , Brice Goglin , Al Viro , Rick Lindsley , David Howells , Marcelo Tosatti , "Eric W. Biederman" , Carlos Maiolino , linux-fsdevel , Kernel Mailing List Subject: Re: [PATCH v6 2/7] kernfs: add a revision to identify directory node changes Message-ID: References: <162322846765.361452.17051755721944717990.stgit@web.messagingengine.com> <162322859985.361452.14110524195807923374.stgit@web.messagingengine.com> <03f6e366fb4ebb56b15541d53eda461a55d3d38e.camel@themaw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <03f6e366fb4ebb56b15541d53eda461a55d3d38e.camel@themaw.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 11, 2021 at 08:56:18PM +0800, Ian Kent wrote: > On Fri, 2021-06-11 at 14:49 +0200, Miklos Szeredi wrote: > > On Wed, 9 Jun 2021 at 10:50, Ian Kent wrote: > > > > > > Add a revision counter to kernfs directory nodes so it can be used > > > to detect if a directory node has changed during negative dentry > > > revalidation. > > > > > > There's an assumption that sizeof(unsigned long) <= sizeof(pointer) > > > on all architectures and as far as I know that assumption holds. > > > > > > So adding a revision counter to the struct kernfs_elem_dir variant > > > of > > > the kernfs_node type union won't increase the size of the > > > kernfs_node > > > struct. This is because struct kernfs_elem_dir is at least > > > sizeof(pointer) smaller than the largest union variant. It's > > > tempting > > > to make the revision counter a u64 but that would increase the size > > > of > > > kernfs_node on archs where sizeof(pointer) is smaller than the > > > revision > > > counter. > > > > > > Signed-off-by: Ian Kent > > > --- > > > ?fs/kernfs/dir.c???????????? |??? 2 ++ > > > ?fs/kernfs/kernfs-internal.h |?? 23 +++++++++++++++++++++++ > > > ?include/linux/kernfs.h????? |??? 5 +++++ > > > ?3 files changed, 30 insertions(+) > > > > > > diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c > > > index 33166ec90a112..b3d1bc0f317d0 100644 > > > --- a/fs/kernfs/dir.c > > > +++ b/fs/kernfs/dir.c > > > @@ -372,6 +372,7 @@ static int kernfs_link_sibling(struct > > > kernfs_node *kn) > > > ??????? /* successfully added, account subdir number */ > > > ??????? if (kernfs_type(kn) == KERNFS_DIR) > > > ??????????????? kn->parent->dir.subdirs++; > > > +?????? kernfs_inc_rev(kn->parent); > > > > > > ??????? return 0; > > > ?} > > > @@ -394,6 +395,7 @@ static bool kernfs_unlink_sibling(struct > > > kernfs_node *kn) > > > > > > ??????? if (kernfs_type(kn) == KERNFS_DIR) > > > ??????????????? kn->parent->dir.subdirs--; > > > +?????? kernfs_inc_rev(kn->parent); > > > > > > ??????? rb_erase(&kn->rb, &kn->parent->dir.children); > > > ??????? RB_CLEAR_NODE(&kn->rb); > > > diff --git a/fs/kernfs/kernfs-internal.h b/fs/kernfs/kernfs- > > > internal.h > > > index ccc3b44f6306f..b4e7579e04799 100644 > > > --- a/fs/kernfs/kernfs-internal.h > > > +++ b/fs/kernfs/kernfs-internal.h > > > @@ -81,6 +81,29 @@ static inline struct kernfs_node > > > *kernfs_dentry_node(struct dentry *dentry) > > > ??????? return d_inode(dentry)->i_private; > > > ?} > > > > > > +static inline void kernfs_set_rev(struct kernfs_node *kn, > > > +???????????????????????????????? struct dentry *dentry) > > > +{ > > > +?????? if (kernfs_type(kn) == KERNFS_DIR) > > > +?????????????? dentry->d_time = kn->dir.rev; > > > +} > > > + > > > +static inline void kernfs_inc_rev(struct kernfs_node *kn) > > > +{ > > > +?????? if (kernfs_type(kn) == KERNFS_DIR) > > > +?????????????? kn->dir.rev++; > > > +} > > > + > > > +static inline bool kernfs_dir_changed(struct kernfs_node *kn, > > > +???????????????????????????????????? struct dentry *dentry) > > > +{ > > > +?????? if (kernfs_type(kn) == KERNFS_DIR) { > > > > Aren't these always be called on a KERNFS_DIR node? > > Yes they are. > > > > > You could just reduce that to a WARN_ON, or remove the conditions > > altogether then. > > I was tempted to not use the check, a WARN_ON sounds better than > removing the check, I'll do that in a v7. No, WARN_ON is not ok, as systems will crash if panic-on-warn is set. If these are impossible to hit, great, let's not check this and we can just drop the code. If they can be hit, then the above code is correct and it should stay. thanks, greg k-h