netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "bfields@fieldses.org" <bfields@fieldses.org>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "neilb@suse.com" <neilb@suse.com>,
	"timo@rothenpieler.org" <timo@rothenpieler.org>,
	"tyhicks@canonical.com" <tyhicks@canonical.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"wanghai38@huawei.com" <wanghai38@huawei.com>,
	"nicolas.dichtel@6wind.com" <nicolas.dichtel@6wind.com>,
	"edumazet@google.com" <edumazet@google.com>,
	"jlayton@kernel.org" <jlayton@kernel.org>,
	"dsahern@gmail.com" <dsahern@gmail.com>,
	"christian.brauner@ubuntu.com" <christian.brauner@ubuntu.com>,
	"jiang.wang@bytedance.com" <jiang.wang@bytedance.com>,
	"anna.schumaker@netapp.com" <anna.schumaker@netapp.com>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"cong.wang@bytedance.com" <cong.wang@bytedance.com>,
	"ast@kernel.org" <ast@kernel.org>,
	"kuniyu@amazon.co.jp" <kuniyu@amazon.co.jp>,
	"willy@infradead.org" <willy@infradead.org>,
	"wenbin.zeng@gmail.com" <wenbin.zeng@gmail.com>,
	"tom@talpey.com" <tom@talpey.com>,
	"chuck.lever@oracle.com" <chuck.lever@oracle.com>,
	"Rao.Shoaib@oracle.com" <Rao.Shoaib@oracle.com>,
	"jakub.kicinski@netronome.com" <jakub.kicinski@netronome.com>,
	"kolga@netapp.com" <kolga@netapp.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@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
Date: Tue, 28 Sep 2021 09:49:52 -0400	[thread overview]
Message-ID: <20210928134952.GA25415@fieldses.org> (raw)
In-Reply-To: <a845b544c6592e58feeaff3be9271a717f53b383.camel@hammerspace.com>

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.

  reply	other threads:[~2021-09-28 13:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-28  3:14 [PATCH net 0/2] auth_gss: Fix netns refcount leaks when use-gss-proxy==1 Wang Hai
2021-09-28  3:14 ` [PATCH net 1/2] net: Modify unix_stream_connect to not reference count the netns of kernel sockets Wang Hai
2021-09-28 12:50   ` Kuniyuki Iwashima
2021-09-28  3:14 ` [PATCH net 2/2] auth_gss: Fix deadlock that blocks rpcsec_gss_exit_net when use-gss-proxy==1 Wang Hai
2021-09-28 13:30   ` Trond Myklebust
2021-09-28 13:49     ` bfields [this message]
2021-09-28 14:04       ` Trond Myklebust
2021-09-28 14:17         ` bfields
2021-09-28 14:27           ` Trond Myklebust
2021-09-28 14:57             ` bfields
2021-09-28 15:36               ` Trond Myklebust
2021-09-28 15:43                 ` bfields
2021-09-29 21:12                   ` bfields
2021-09-30  1:56                     ` wanghai (M)
2021-11-09 17:21                       ` bfields
2021-11-17 19:19                         ` bfields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210928134952.GA25415@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Rao.Shoaib@oracle.com \
    --cc=anna.schumaker@netapp.com \
    --cc=ast@kernel.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=chuck.lever@oracle.com \
    --cc=cong.wang@bytedance.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=edumazet@google.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=jiang.wang@bytedance.com \
    --cc=jlayton@kernel.org \
    --cc=kolga@netapp.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@amazon.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.com \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    --cc=timo@rothenpieler.org \
    --cc=tom@talpey.com \
    --cc=trondmy@hammerspace.com \
    --cc=tyhicks@canonical.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wanghai38@huawei.com \
    --cc=wenbin.zeng@gmail.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).