From: Al Viro <viro@zeniv.linux.org.uk>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ian Kent <raven@themaw.net>, Tejun Heo <tj@kernel.org>,
Hou Tao <houtao1@huawei.com>, David Howells <dhowells@redhat.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Rick Lindsley <ricklind@linux.vnet.ibm.com>,
Carlos Maiolino <cmaiolino@redhat.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [REPOST,UPDATED PATCH] kernfs: don't create a negative dentry if inactive node exists
Date: Mon, 4 Oct 2021 06:12:44 +0000 [thread overview]
Message-ID: <YVqbXADscqYEBaFZ@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <YVqZSz3d60IVjpTh@kroah.com>
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>
prev parent reply other threads:[~2021-10-04 6:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 1:03 [REPOST,UPDATED PATCH] kernfs: don't create a negative dentry if inactive node exists Ian Kent
2021-10-04 1:07 ` Al Viro
2021-10-04 6:03 ` Greg Kroah-Hartman
2021-10-04 6:12 ` Al Viro [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YVqbXADscqYEBaFZ@zeniv-ca.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=cmaiolino@redhat.com \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=houtao1@huawei.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=raven@themaw.net \
--cc=ricklind@linux.vnet.ibm.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.