Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp4913280pxb; Tue, 28 Sep 2021 06:50:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztguQhW7sGIKGAtQNXSB7WslIcr53Rficgh7ERdR5oAQknvT58GNKw1r5U0os9epGQAcc5 X-Received: by 2002:a17:902:b102:b0:134:a329:c2f8 with SMTP id q2-20020a170902b10200b00134a329c2f8mr5256288plr.71.1632837037683; Tue, 28 Sep 2021 06:50:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632837037; cv=none; d=google.com; s=arc-20160816; b=FihpYaXXG0IPqLU0XERtscpyCu9AZXH33bxZLwKaf9o+Maqdl4q0Ngf/Dx3BLa1f8A e231DAty8f4+LAtp7CtS6X7vC/dcfgXGR1pBlFN3uCmfp4j6cX3/wkDMzd+4znWmIgDk gcFvcERCs4eYwQQDdkUVVmY3Ovz4mOxpv/6y8qCWXIJyIN64nBzTUon4KSREh16he952 xyDn0fooRSRMIkAPC2OW5bwtNSuMwmutpLBR90B8mD6sTHi7pxXuGCoAieGrXT9ijbo0 /0qddVAQRwj81HGTB25TjbYdytJ6gTTG29Hrn2vkPGyOw/fCThNWodJQx9IKSOCB7K30 UW9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:dkim-filter; bh=gJgOMPKzYEwoXYQGRIcnNhlyKucOcati169rQJkAD9o=; b=WQAd/vIw3cNV2I2AIu8S12u0MFK9mCJi7XwmVrdG4aHnKsAw0LOi21ZHGutfi6gRvP yMBag/eYtHXoirI2CogwQj+ZLeM0wy+ZCBJxYaOMazoHh7hwFIsaOxCT21yDeDB5DX93 sPUBVEv+WabPe1MeS+/qL1+gmsy7Vdk2sS632pGOyLyXdZni/ymnt+50xq7LYafo9+cb F7C4TvIZdra9Q1eozcKYA2PwphwFg9o1f71L2qDqLPEmg6Z4r2Qg/rrK83FalG8r7fIY ZXlckBJGRyJJSre1jTGxeEvBZfZ4WSHt7nrIopVPEIKGGzcD6IE4Bpuh5JU+OWM0r5X3 zvtg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=WgZhwnwF; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e33si28610944pge.288.2021.09.28.06.49.58; Tue, 28 Sep 2021 06:50:37 -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; dkim=pass header.i=@fieldses.org header.s=default header.b=WgZhwnwF; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241027AbhI1Nve (ORCPT + 99 others); Tue, 28 Sep 2021 09:51:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241004AbhI1Nvd (ORCPT ); Tue, 28 Sep 2021 09:51:33 -0400 Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6204FC061575; Tue, 28 Sep 2021 06:49:54 -0700 (PDT) Received: by fieldses.org (Postfix, from userid 2815) id 0692BAB8; Tue, 28 Sep 2021 09:49:53 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org 0692BAB8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1632836993; bh=gJgOMPKzYEwoXYQGRIcnNhlyKucOcati169rQJkAD9o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WgZhwnwFrnNnJTABoQvcAjU3M2mrCFLPBwjDj0extZ446bc6qCQhdicln5t5cX89c +eV+DrKT+NiM5lNDo3LRYQrw9CwO6cd1H+Di0vwMHb2MChb6yfd5wAAmQ8uf5Ne5a/ TK/0wQwdc/SAmjHB/PdY/S0kRrzVBtNrfupyUvyk= Date: Tue, 28 Sep 2021 09:49:52 -0400 From: "bfields@fieldses.org" To: Trond Myklebust Cc: "neilb@suse.com" , "timo@rothenpieler.org" , "tyhicks@canonical.com" , "davem@davemloft.net" , "wanghai38@huawei.com" , "nicolas.dichtel@6wind.com" , "edumazet@google.com" , "jlayton@kernel.org" , "dsahern@gmail.com" , "christian.brauner@ubuntu.com" , "jiang.wang@bytedance.com" , "anna.schumaker@netapp.com" , "viro@zeniv.linux.org.uk" , "kuba@kernel.org" , "cong.wang@bytedance.com" , "ast@kernel.org" , "kuniyu@amazon.co.jp" , "willy@infradead.org" , "wenbin.zeng@gmail.com" , "tom@talpey.com" , "chuck.lever@oracle.com" , "Rao.Shoaib@oracle.com" , "jakub.kicinski@netronome.com" , "kolga@netapp.com" , "linux-nfs@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH net 2/2] auth_gss: Fix deadlock that blocks rpcsec_gss_exit_net when use-gss-proxy==1 Message-ID: <20210928134952.GA25415@fieldses.org> References: <20210928031440.2222303-1-wanghai38@huawei.com> <20210928031440.2222303-3-wanghai38@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Tue, Sep 28, 2021 at 01:30:17PM +0000, Trond Myklebust wrote: > On Tue, 2021-09-28 at 11:14 +0800, Wang Hai wrote: > > When use-gss-proxy is set to 1, write_gssp() creates a rpc client in > > gssp_rpc_create(), this increases the netns refcount by 2, 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 > > the 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. So, in this case, the netns refcount > > should not be increased. > > > > In this case, xprt will take a netns refcount which is not supposed > > to be taken. Add a new flag to rpc_create_args called > > RPC_CLNT_CREATE_NO_NET_REF for not increasing the netns refcount. > > > > It is safe not to hold the netns refcount, because when > > cleanup_net(), it > > will hold the gssp_lock and then shut down the rpc client > > synchronously. > > > > > I don't like this solution at all. Adding this kind of flag is going to > lead to problems down the road. > > Is there any reason whatsoever why we need this RPC client to exist > when there is no active knfsd server? IOW: Is there any reason why we > shouldn't defer creating this RPC client for when knfsd starts up in > this net namespace, and why we can't shut it down when knfsd shuts > down? The rpc create is done in the context of the process that writes to /proc/net/rpc/use-gss-proxy to get the right namespaces. I don't know how hard it would be capture that information for a later create. --b.