[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190510.151333.266788690200661708.davem@davemloft.net>
Date: Fri, 10 May 2019 15:13:33 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: wenbin.zeng@...il.com
Cc: bfields@...ldses.org, viro@...iv.linux.org.uk, 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 v2 2/3] netns: add netns_evict into netns_operations
From: Wenbin Zeng <wenbin.zeng@...il.com>
Date: Fri, 10 May 2019 14:36:02 +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