[PATCH] SUNRPC: 'Directory with parent 'rpc_clnt' already present!'

[PATCH] SUNRPC: 'Directory with parent 'rpc_clnt' already present!'

[J. Bruce Fields]

From: "J. Bruce Fields" <bfields@redhat.com>

Each rpc_client has a cl_clid which is allocated from a global ida, and
a debugfs directory which is named after cl_clid.

We're releasing the cl_clid before we free the debugfs directory named
after it.  As soon as the cl_clid is released, that value is available
for another newly created client.

That leaves a window where another client may attempt to create a new
debugfs directory with the same name as the not-yet-deleted debugfs
directory from the dying client.  Symptoms are log messages like

	Directory 4 with parent 'rpc_clnt' already present!

Fixes: 7c4310ff5642 "SUNRPC: defer slow parts of rpc_free_client() to a workqueue."
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
---
 net/sunrpc/clnt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 8350d3a2e9a7..4a7efc00fd83 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -889,6 +889,7 @@ static void rpc_free_client_work(struct work_struct *work)
 	 * here.
 	 */
 	rpc_clnt_debugfs_unregister(clnt);
+	rpc_free_clid(clnt);
 	rpc_clnt_remove_pipedir(clnt);
 
 	kfree(clnt);
@@ -910,7 +911,6 @@ rpc_free_client(struct rpc_clnt *clnt)
 	xprt_put(rcu_dereference_raw(clnt->cl_xprt));
 	xprt_iter_destroy(&clnt->cl_xpi);
 	put_cred(clnt->cl_cred);
-	rpc_free_clid(clnt);
 
 	INIT_WORK(&clnt->cl_work, rpc_free_client_work);
 	schedule_work(&clnt->cl_work);
-- 
2.26.2

Re: [PATCH] SUNRPC: 'Directory with parent 'rpc_clnt' already present!'

[J. Bruce Fields]

On Wed, May 13, 2020 at 06:38:40PM -0400, J. Bruce Fields wrote:
> From: "J. Bruce Fields" <bfields@redhat.com>
> 
> Each rpc_client has a cl_clid which is allocated from a global ida, and
> a debugfs directory which is named after cl_clid.
> 
> We're releasing the cl_clid before we free the debugfs directory named
> after it.  As soon as the cl_clid is released, that value is available
> for another newly created client.
> 
> That leaves a window where another client may attempt to create a new
> debugfs directory with the same name as the not-yet-deleted debugfs
> directory from the dying client.  Symptoms are log messages like
> 
> 	Directory 4 with parent 'rpc_clnt' already present!

This also cleared up a "file-max limit 199277 reached" warning, which
suggests to me a leak in an error path somewhere (I think everything's
supposed to work normally even if debugfs file createion fails), but I
don't see it.

--b.

> 
> Fixes: 7c4310ff5642 "SUNRPC: defer slow parts of rpc_free_client() to a workqueue."
> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> ---
>  net/sunrpc/clnt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> index 8350d3a2e9a7..4a7efc00fd83 100644
> --- a/net/sunrpc/clnt.c
> +++ b/net/sunrpc/clnt.c
> @@ -889,6 +889,7 @@ static void rpc_free_client_work(struct work_struct *work)
>  	 * here.
>  	 */
>  	rpc_clnt_debugfs_unregister(clnt);
> +	rpc_free_clid(clnt);
>  	rpc_clnt_remove_pipedir(clnt);
>  
>  	kfree(clnt);
> @@ -910,7 +911,6 @@ rpc_free_client(struct rpc_clnt *clnt)
>  	xprt_put(rcu_dereference_raw(clnt->cl_xprt));
>  	xprt_iter_destroy(&clnt->cl_xpi);
>  	put_cred(clnt->cl_cred);
> -	rpc_free_clid(clnt);
>  
>  	INIT_WORK(&clnt->cl_work, rpc_free_client_work);
>  	schedule_work(&clnt->cl_work);
> -- 
> 2.26.2

Re: [PATCH] SUNRPC: 'Directory with parent 'rpc_clnt' already present!'

[J. Bruce Fields]

On Wed, May 13, 2020 at 06:40:33PM -0400, J. Bruce Fields wrote:
> On Wed, May 13, 2020 at 06:38:40PM -0400, J. Bruce Fields wrote:
> > From: "J. Bruce Fields" <bfields@redhat.com>
> > 
> > Each rpc_client has a cl_clid which is allocated from a global ida, and
> > a debugfs directory which is named after cl_clid.
> > 
> > We're releasing the cl_clid before we free the debugfs directory named
> > after it.  As soon as the cl_clid is released, that value is available
> > for another newly created client.
> > 
> > That leaves a window where another client may attempt to create a new
> > debugfs directory with the same name as the not-yet-deleted debugfs
> > directory from the dying client.  Symptoms are log messages like
> > 
> > 	Directory 4 with parent 'rpc_clnt' already present!
> 
> This also cleared up a "file-max limit 199277 reached" warning, which
> suggests to me a leak in an error path somewhere (I think everything's
> supposed to work normally even if debugfs file createion fails), but I
> don't see it.

Whoops, I spoke to soon, I'm still seeing that warning, so that's an
unrelated issue.

--b.