[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <717504ebff4d1c7506897d1fd8e6550d9969d983.camel@hammerspace.com>
Date: Thu, 8 Apr 2021 16:02:43 +0000
From: Trond Myklebust <trondmy@...merspace.com>
To: "aglo@...ch.edu" <aglo@...ch.edu>
CC: "anna.schumaker@...app.com" <anna.schumaker@...app.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"chuck.lever@...cle.com" <chuck.lever@...cle.com>,
"dwysocha@...hat.com" <dwysocha@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kuba@...nel.org" <kuba@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"bfields@...ldses.org" <bfields@...ldses.org>,
"pakki001@....edu" <pakki001@....edu>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>
Subject: Re: [PATCH] SUNRPC: Add a check for gss_release_msg
On Thu, 2021-04-08 at 11:24 -0400, Olga Kornievskaia wrote:
> On Thu, Apr 8, 2021 at 11:01 AM Trond Myklebust <
> trondmy@...merspace.com> wrote:
> >
> > On Tue, 2021-04-06 at 19:16 -0500, Aditya Pakki wrote:
> > > In gss_pipe_destroy_msg(), in case of error in msg,
> > > gss_release_msg
> > > deletes gss_msg. The patch adds a check to avoid a potential
> > > double
> > > free.
> > >
> > > Signed-off-by: Aditya Pakki <pakki001@....edu>
> > > ---
> > > net/sunrpc/auth_gss/auth_gss.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/net/sunrpc/auth_gss/auth_gss.c
> > > b/net/sunrpc/auth_gss/auth_gss.c
> > > index 5f42aa5fc612..eb52eebb3923 100644
> > > --- a/net/sunrpc/auth_gss/auth_gss.c
> > > +++ b/net/sunrpc/auth_gss/auth_gss.c
> > > @@ -848,7 +848,8 @@ gss_pipe_destroy_msg(struct rpc_pipe_msg
> > > *msg)
> > > warn_gssd();
> > > gss_release_msg(gss_msg);
> > > }
> > > - gss_release_msg(gss_msg);
> > > + if (gss_msg)
> > > + gss_release_msg(gss_msg);
> > > }
> > >
> > > static void gss_pipe_dentry_destroy(struct dentry *dir,
> >
> >
> > NACK. There's no double free there.
>
> I disagree that there is no double free, the wording of the commit
> describes the problem in the error case is that we call
> gss_release_msg() and then we call it again but the 1st one released
> the gss_msg. However, I think the fix should probably be instead:
> diff --git a/net/sunrpc/auth_gss/auth_gss.c
> b/net/sunrpc/auth_gss/auth_gss.c
> index 5f42aa5fc612..e8aae617e981 100644
> --- a/net/sunrpc/auth_gss/auth_gss.c
> +++ b/net/sunrpc/auth_gss/auth_gss.c
> @@ -846,7 +846,7 @@ gss_pipe_destroy_msg(struct rpc_pipe_msg *msg)
> gss_unhash_msg(gss_msg);
> if (msg->errno == -ETIMEDOUT)
> warn_gssd();
> - gss_release_msg(gss_msg);
> + return gss_release_msg(gss_msg);
> }
> gss_release_msg(gss_msg);
> }
>
Please look one line further up: there is a refcount_inc() that matches
that first gss_release_msg(). Removing that call results in a
reintroduction of the leak that Neil fixed in commit 1cded9d2974fe
("SUNRPC: fix refcounting problems with auth_gss messages.").
We might, however, instead opt to remove both the refcount_inc() and
matching gss_release_msg(). Those do seem to be redundant, given that
the caller also holds a refcount.
> >
> > --
> > Trond Myklebust
> > Linux NFS client maintainer, Hammerspace
> > trond.myklebust@...merspace.com
> >
> >
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@...merspace.com
Powered by blists - more mailing lists