From: "J. Bruce Fields" <[email protected]>
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 <[email protected]>
---
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
On Wed, May 13, 2020 at 06:38:40PM -0400, J. Bruce Fields wrote:
> From: "J. Bruce Fields" <[email protected]>
>
> 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 <[email protected]>
> ---
> 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
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" <[email protected]>
> >
> > 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.