Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp4522973pxb; Mon, 27 Sep 2021 20:16:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxkCz+Q8QEMC2d/VdEbzhAq0aCBpjYd7swTxIZ1uwOePTtZ/7gHANHTflVXwTSEgk2ot3TL X-Received: by 2002:a17:90b:1649:: with SMTP id il9mr2862549pjb.206.1632798961214; Mon, 27 Sep 2021 20:16:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632798961; cv=none; d=google.com; s=arc-20160816; b=IMngp41lbQq6jAcLhY99b3OPAo9r0mt8wIaAQyRaPDZW3m62xjTSc/6P02QeVJtvjU FL2HTP/cUaILpHvOygbG2sWrSC+xRAcWG4hN/aJWDe8+1IRkuvfQPqCyBRwJeh9bexqF Qxma1i5wIz6cCdkN1hOln7mWeNi8euuRdEh3clvWgc9C0XYe2TJd39w41+tLyaJm6+E7 cdnge2fXqvtFLkbn7BHOqCRHn6B7JRQb088P0+ZyNXi45yi8KZ2SSbvqChznb6jGYcg0 mLInmQiaXptGOoLsVSl644cRIyQxoQAS3mWSjuSFEoXLtt2B7CQCDOIy2xdU5+RZB7Mk 3Q6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=FJ9CpHzgfWiYP+Jf4yrz7eKFDcRZEwZd7YwmcPIz3Ng=; b=mNQkEJRwYyxEWTDfO2MzGNPgURoVmhgOxT5qof+WkAjZETsM88uGl2kuAOAaoR0xN9 +FtWT5Tvyh0RKOcMKY2Sbot4MxXo7nitKthOaHOZDm+lNCrkAzu8Qf15fjUbu/WoIwZo u/bsWUkl9rKOuAj2t/pHVeYFhJ9qT5E3zzHqQqXEcsgqkmlpo8y95CFzvkcS+VUJFdHI YQ9ByBliwyHSx31altOfEmklDW2cG8sQIaotYM2hvBvC90q7ldevLRI6QrEUh2ilwgiz qdFDwur1wHBZ59c3lqGBuzjpN/kDzdaPZi46u35cVgfCuzBZFU50wwsdJwPnLF/HSOmA N6/g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n63si23961183pfn.194.2021.09.27.20.15.47; Mon, 27 Sep 2021 20:16:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238781AbhI1DRV (ORCPT + 99 others); Mon, 27 Sep 2021 23:17:21 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:26917 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238748AbhI1DRU (ORCPT ); Mon, 27 Sep 2021 23:17:20 -0400 Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4HJPfg3vdzzbm9Z; Tue, 28 Sep 2021 11:11:23 +0800 (CST) Received: from kwepemm600001.china.huawei.com (7.193.23.3) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 28 Sep 2021 11:15:39 +0800 Received: from huawei.com (10.175.104.82) by kwepemm600001.china.huawei.com (7.193.23.3) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 28 Sep 2021 11:15:37 +0800 From: Wang Hai To: , , , , , , , , , , , , , , , , , , , , , , , , CC: , , Subject: [PATCH net 0/2] auth_gss: Fix netns refcount leaks when use-gss-proxy==1 Date: Tue, 28 Sep 2021 11:14:38 +0800 Message-ID: <20210928031440.2222303-1-wanghai38@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.104.82] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600001.china.huawei.com (7.193.23.3) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org When use-gss-proxy is set to 1, write_gssp() creates a rpc client in gssp_rpc_create(), this increases netns refcount by 2 [1], these refcounts are supposed to be released in rpcsec_gss_exit_net(), but it will never happen because rpcsec_gss_exit_net() is triggered only when netns refcount gets to 0, specifically: refcount=0 -> cleanup_net() -> ops_exit_list -> rpcsec_gss_exit_net It is a deadlock situation here, refcount will never get to 0 unless rpcsec_gss_exit_net() is called. [1] SyS_write vfs_write proc_reg_write write_gssp set_gssp_clnt gssp_rpc_create rpc_create xprt_create_transport xs_setup_local xs_setup_xprt xprt_alloc // get net refcount xs_local_setup_socket unix_create kernel_connect // get net refcount In this case, the net refcount shouldn't be increased when creating rpc client, otherwise it will lead to deadlock. This patchset removes the increased netns reference count. Wang Hai (2): net: Modify unix_stream_connect to not reference count the netns of kernel sockets auth_gss: Fix deadlock that blocks rpcsec_gss_exit_net when use-gss-proxy==1 include/linux/sunrpc/clnt.h | 1 + include/linux/sunrpc/xprt.h | 6 ++++-- net/sunrpc/auth_gss/gss_rpc_upcall.c | 3 ++- net/sunrpc/clnt.c | 2 ++ net/sunrpc/xprt.c | 13 +++++++++---- net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 2 +- net/sunrpc/xprtrdma/transport.c | 2 +- net/sunrpc/xprtsock.c | 4 +++- net/unix/af_unix.c | 3 ++- 9 files changed, 25 insertions(+), 11 deletions(-) -- 2.17.1