| 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 |
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...
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
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 --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);
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(-)