[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190504.001025.1191902881190952783.davem@davemloft.net>
Date: Sat, 04 May 2019 00:10:25 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: wenbin.zeng@...il.com
Cc: viro@...iv.linux.org.uk, bfields@...ldses.org, jlayton@...nel.org,
trond.myklebust@...merspace.com, anna.schumaker@...app.com,
wenbinzeng@...cent.com, dsahern@...il.com,
nicolas.dichtel@...nd.com, willy@...radead.org,
edumazet@...gle.com, jakub.kicinski@...ronome.com,
tyhicks@...onical.com, chuck.lever@...cle.com, neilb@...e.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, linux-nfs@...r.kernel.org
Subject: Re: [PATCH 2/3] netns: add netns_evict into netns_operations
From: Wenbin Zeng <wenbin.zeng@...il.com>
Date: Wed, 1 May 2019 14:42:24 +0800
> The newly added netns_evict() shall be called when the netns inode being
> evicted. It provides another path to release netns refcounts, previously
> netns_put() is the only choice, but it is not able to release all netns
> refcount, for example, a rpc client holds two netns refcounts, these
> refcounts are supposed to be released when the rpc client is freed, but
> the code to free rpc client is normally triggered by put() callback only
> when netns refcount gets to 0, specifically:
> refcount=0 -> cleanup_net() -> ops_exit_list -> free rpc client
> But netns refcount will never get to 0 before rpc client gets freed, to
> break the deadlock, the code to free rpc client can be put into the newly
> added netns_evict.
>
> Signed-off-by: Wenbin Zeng <wenbinzeng@...cent.com>
Acked-by: David S. Miller <davem@...emloft.net>
Powered by blists - more mailing lists