diff mbox series

[REPOST,UPDATED] kernfs: don't create a negative dentry if inactive node exists

Message ID 163330943316.19450.15056895533949392922.stgit@mickey.themaw.net (mailing list archive)
State New, archived
Headers show
Series [REPOST,UPDATED] kernfs: don't create a negative dentry if inactive node exists | expand

Commit Message

Ian Kent Oct. 4, 2021, 1:03 a.m. UTC
It's been reported that doing stress test for module insertion and
removal can result in an ENOENT from libkmod for a valid module.

In kernfs_iop_lookup() a negative dentry is created if there's no kernfs
node associated with the dentry or the node is inactive.

But inactive kernfs nodes are meant to be invisible to the VFS and
creating a negative dentry for these can have unexpected side effects
when the node transitions to an active state.

The point of creating negative dentries is to avoid the expensive
alloc/free cycle that occurs if there are frequent lookups for kernfs
attributes that don't exist. So kernfs nodes that are not yet active
should not result in a negative dentry being created so when they
transition to an active state VFS lookups can create an associated
dentry is a natural way.

It's also been reported that https://github.com/osandov/blktests.git
test block/001 hangs during the test. It was suggested that recent
changes to blktests might have caused it but applying this patch
resolved the problem without change to blktests.

Fixes: c7e7c04274b1 ("kernfs: use VFS negative dentry caching")
Tested-by: Yi Zhang <yi.zhang@redhat.com>
Signed-off-by: Ian Kent <raven@themaw.net>
---
 fs/kernfs/dir.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Comments

Al Viro Oct. 4, 2021, 1:07 a.m. UTC | #1
On Mon, Oct 04, 2021 at 09:03:53AM +0800, Ian Kent wrote:
> It's been reported that doing stress test for module insertion and
> removal can result in an ENOENT from libkmod for a valid module.
> 
> In kernfs_iop_lookup() a negative dentry is created if there's no kernfs
> node associated with the dentry or the node is inactive.
> 
> But inactive kernfs nodes are meant to be invisible to the VFS and
> creating a negative dentry for these can have unexpected side effects
> when the node transitions to an active state.
> 
> The point of creating negative dentries is to avoid the expensive
> alloc/free cycle that occurs if there are frequent lookups for kernfs
> attributes that don't exist. So kernfs nodes that are not yet active
> should not result in a negative dentry being created so when they
> transition to an active state VFS lookups can create an associated
> dentry is a natural way.
> 
> It's also been reported that https://github.com/osandov/blktests.git
> test block/001 hangs during the test. It was suggested that recent
> changes to blktests might have caused it but applying this patch
> resolved the problem without change to blktests.

Looks sane, but which tree should it go through?  I can pick it, but I've
no idea if anybody already has kernfs work in their trees...
Greg Kroah-Hartman Oct. 4, 2021, 6:03 a.m. UTC | #2
On Mon, Oct 04, 2021 at 01:07:46AM +0000, Al Viro wrote:
> On Mon, Oct 04, 2021 at 09:03:53AM +0800, Ian Kent wrote:
> > It's been reported that doing stress test for module insertion and
> > removal can result in an ENOENT from libkmod for a valid module.
> > 
> > In kernfs_iop_lookup() a negative dentry is created if there's no kernfs
> > node associated with the dentry or the node is inactive.
> > 
> > But inactive kernfs nodes are meant to be invisible to the VFS and
> > creating a negative dentry for these can have unexpected side effects
> > when the node transitions to an active state.
> > 
> > The point of creating negative dentries is to avoid the expensive
> > alloc/free cycle that occurs if there are frequent lookups for kernfs
> > attributes that don't exist. So kernfs nodes that are not yet active
> > should not result in a negative dentry being created so when they
> > transition to an active state VFS lookups can create an associated
> > dentry is a natural way.
> > 
> > It's also been reported that https://github.com/osandov/blktests.git
> > test block/001 hangs during the test. It was suggested that recent
> > changes to blktests might have caused it but applying this patch
> > resolved the problem without change to blktests.
> 
> Looks sane, but which tree should it go through?  I can pick it, but I've
> no idea if anybody already has kernfs work in their trees...

I can take it, kernfs patches normally go through my tree, can I get an
acked-by?

thanks,

greg k-h
Al Viro Oct. 4, 2021, 6:12 a.m. UTC | #3
On Mon, Oct 04, 2021 at 08:03:55AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Oct 04, 2021 at 01:07:46AM +0000, Al Viro wrote:
> > On Mon, Oct 04, 2021 at 09:03:53AM +0800, Ian Kent wrote:
> > > It's been reported that doing stress test for module insertion and
> > > removal can result in an ENOENT from libkmod for a valid module.
> > > 
> > > In kernfs_iop_lookup() a negative dentry is created if there's no kernfs
> > > node associated with the dentry or the node is inactive.
> > > 
> > > But inactive kernfs nodes are meant to be invisible to the VFS and
> > > creating a negative dentry for these can have unexpected side effects
> > > when the node transitions to an active state.
> > > 
> > > The point of creating negative dentries is to avoid the expensive
> > > alloc/free cycle that occurs if there are frequent lookups for kernfs
> > > attributes that don't exist. So kernfs nodes that are not yet active
> > > should not result in a negative dentry being created so when they
> > > transition to an active state VFS lookups can create an associated
> > > dentry is a natural way.
> > > 
> > > It's also been reported that https://github.com/osandov/blktests.git
> > > test block/001 hangs during the test. It was suggested that recent
> > > changes to blktests might have caused it but applying this patch
> > > resolved the problem without change to blktests.
> > 
> > Looks sane, but which tree should it go through?  I can pick it, but I've
> > no idea if anybody already has kernfs work in their trees...
> 
> I can take it, kernfs patches normally go through my tree, can I get an
> acked-by?

ACKed-by: Al Viro <viro@zeniv.linux.org.uk>
diff mbox series

Patch

diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index ba581429bf7b..a957c944cf3a 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -1111,7 +1111,14 @@  static struct dentry *kernfs_iop_lookup(struct inode *dir,
 
 	kn = kernfs_find_ns(parent, dentry->d_name.name, ns);
 	/* attach dentry and inode */
-	if (kn && kernfs_active(kn)) {
+	if (kn) {
+		/* Inactive nodes are invisible to the VFS so don't
+		 * create a negative.
+		 */
+		if (!kernfs_active(kn)) {
+			up_read(&kernfs_rwsem);
+			return NULL;
+		}
 		inode = kernfs_get_inode(dir->i_sb, kn);
 		if (!inode)
 			inode = ERR_PTR(-ENOMEM);