From: J. Bruce Fields <bfields@xxxxxxxxxx>
If rpc_queue_upcall() adds a new upcall to the rpci->pipe list just
after rpc_pipe_release calls rpc_purge_list(), but before it calls
gss_pipe_release (as rpci->ops->release_pipe(inode)), then the latter
will free a message without deleting it from the rpci->pipe list.
We will be left with a freed object on the rpc->pipe list. Most
frequent symptoms are kernel crashes in rpc.gssd system calls on the
pipe in question.
We could just add a list_del(&gss_msg->msg.list) here. But I can see no
reason for doing all this cleanup here; the preceding rpc_purge_list()
should have done the job, except possibly for any newly queued upcalls
as above, which can safely be left to wait for another opener.
Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxx>
---
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index 36eee66..8ad9a34 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -744,23 +744,6 @@ static int gss_pipe_open_v1(struct inode *inode)
static void
gss_pipe_release(struct inode *inode)
{
- struct rpc_inode *rpci = RPC_I(inode);
- struct gss_upcall_msg *gss_msg;
-
- spin_lock(&inode->i_lock);
- while (!list_empty(&rpci->in_downcall)) {
-
- gss_msg = list_entry(rpci->in_downcall.next,
- struct gss_upcall_msg, list);
- gss_msg->msg.errno = -EPIPE;
- atomic_inc(&gss_msg->count);
- __gss_unhash_msg(gss_msg);
- spin_unlock(&inode->i_lock);
- gss_release_msg(gss_msg);
- spin_lock(&inode->i_lock);
- }
- spin_unlock(&inode->i_lock);
-
put_pipe_version();
}
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
