* [PATCH net-next 0/3] tipc: fix netns refcnt leak
@ 2015-03-18 1:32 Ying Xue
2015-03-18 1:32 ` [PATCH net-next 1/3] " Ying Xue
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Ying Xue @ 2015-03-18 1:32 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, cwang, tipc-discussion, netdev
The series aims to eliminate the issue of netns refcount leak. But
during fixing it, another two additional problems are found. So all
of known issues associated with the netns refcnt leak are resolved
at the same time in the patchset.
Ying Xue (3):
tipc: fix netns refcnt leak
tipc: fix a potential deadlock when nametable is purged
tipc: withdraw tipc topology server name when namespace is deleted
net/tipc/name_table.c | 4 +--
net/tipc/server.c | 47 ++++++++++++++++++++++++----
net/tipc/socket.c | 83 +------------------------------------------------
net/tipc/socket.h | 4 ---
4 files changed, 44 insertions(+), 94 deletions(-)
--
1.7.9.5
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH net-next 1/3] tipc: fix netns refcnt leak
2015-03-18 1:32 [PATCH net-next 0/3] tipc: fix netns refcnt leak Ying Xue
@ 2015-03-18 1:32 ` Ying Xue
2015-03-18 1:32 ` [PATCH net-next 2/3] tipc: fix a potential deadlock when nametable is purged Ying Xue
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Ying Xue @ 2015-03-18 1:32 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, cwang, erik.hugne, netdev, tipc-discussion
When the TIPC module is loaded, we launch a topology server in kernel
space, which in its turn is creating TIPC sockets for communication
with topology server users. Because both the socket's creator and
provider reside in the same module, it is necessary that the TIPC
module's reference count remains zero after the server is started and
the socket created; otherwise it becomes impossible to perform "rmmod"
even on an idle module.
Currently, we achieve this by defining a separate "tipc_proto_kern"
protocol struct, that is used only for kernel space socket allocations.
This structure has the "owner" field set to NULL, which restricts the
module reference count from being be bumped when sk_alloc() for local
sockets is called. Furthermore, we have defined three kernel-specific
functions, tipc_sock_create_local(), tipc_sock_release_local() and
tipc_sock_accept_local(), to avoid the module counter being modified
when module local sockets are created or deleted. This has worked well
until we introduced name space support.
However, after name space support was introduced, we have observed that
a reference count leak occurs, because the netns counter is not
decremented in tipc_sock_delete_local().
This commit remedies this problem. But instead of just modifying
tipc_sock_delete_local(), we eliminate the whole parallel socket
handling infrastructure, and start using the regular sk_create_kern(),
kernel_accept() and sk_release_kernel() calls. Since those functions
manipulate the module counter, we must now compensate for that by
explicitly decrementing the counter after module local sockets are
created, and increment it just before calling sk_release_kernel().
Fixes: a62fbccecd62 ("tipc: make subscriber server support net namespace")
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Reported-by: Cong Wang <cwang@twopensource.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/server.c | 44 ++++++++++++++++++++++++----
net/tipc/socket.c | 83 +----------------------------------------------------
net/tipc/socket.h | 4 ---
3 files changed, 39 insertions(+), 92 deletions(-)
diff --git a/net/tipc/server.c b/net/tipc/server.c
index eadd4ed..a57c840 100644
--- a/net/tipc/server.c
+++ b/net/tipc/server.c
@@ -37,11 +37,13 @@
#include "core.h"
#include "socket.h"
#include <net/sock.h>
+#include <linux/module.h>
/* Number of messages to send before rescheduling */
#define MAX_SEND_MSG_COUNT 25
#define MAX_RECV_MSG_COUNT 25
#define CF_CONNECTED 1
+#define CF_SERVER 2
#define sock2con(x) ((struct tipc_conn *)(x)->sk_user_data)
@@ -88,9 +90,16 @@ static void tipc_clean_outqueues(struct tipc_conn *con);
static void tipc_conn_kref_release(struct kref *kref)
{
struct tipc_conn *con = container_of(kref, struct tipc_conn, kref);
+ struct socket *sock = con->sock;
+ struct sock *sk;
- if (con->sock) {
- tipc_sock_release_local(con->sock);
+ if (sock) {
+ sk = sock->sk;
+ if (test_bit(CF_SERVER, &con->flags)) {
+ __module_get(sock->ops->owner);
+ __module_get(sk->sk_prot_creator->owner);
+ }
+ sk_release_kernel(sk);
con->sock = NULL;
}
@@ -281,7 +290,7 @@ static int tipc_accept_from_sock(struct tipc_conn *con)
struct tipc_conn *newcon;
int ret;
- ret = tipc_sock_accept_local(sock, &newsock, O_NONBLOCK);
+ ret = kernel_accept(sock, &newsock, O_NONBLOCK);
if (ret < 0)
return ret;
@@ -309,9 +318,12 @@ static struct socket *tipc_create_listen_sock(struct tipc_conn *con)
struct socket *sock = NULL;
int ret;
- ret = tipc_sock_create_local(s->net, s->type, &sock);
+ ret = sock_create_kern(AF_TIPC, SOCK_SEQPACKET, 0, &sock);
if (ret < 0)
return NULL;
+
+ sk_change_net(sock->sk, s->net);
+
ret = kernel_setsockopt(sock, SOL_TIPC, TIPC_IMPORTANCE,
(char *)&s->imp, sizeof(s->imp));
if (ret < 0)
@@ -337,11 +349,31 @@ static struct socket *tipc_create_listen_sock(struct tipc_conn *con)
pr_err("Unknown socket type %d\n", s->type);
goto create_err;
}
+
+ /* As server's listening socket owner and creator is the same module,
+ * we have to decrease TIPC module reference count to guarantee that
+ * it remains zero after the server socket is created, otherwise,
+ * executing "rmmod" command is unable to make TIPC module deleted
+ * after TIPC module is inserted successfully.
+ *
+ * However, the reference count is ever increased twice in
+ * sock_create_kern(): one is to increase the reference count of owner
+ * of TIPC socket's proto_ops struct; another is to increment the
+ * reference count of owner of TIPC proto struct. Therefore, we must
+ * decrement the module reference count twice to ensure that it keeps
+ * zero after server's listening socket is created. Of course, we
+ * must bump the module reference count twice as well before the socket
+ * is closed.
+ */
+ module_put(sock->ops->owner);
+ module_put(sock->sk->sk_prot_creator->owner);
+ set_bit(CF_SERVER, &con->flags);
+
return sock;
create_err:
- sock_release(sock);
- con->sock = NULL;
+ kernel_sock_shutdown(sock, SHUT_RDWR);
+ sk_release_kernel(sock->sk);
return NULL;
}
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 934947f..813847d 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -121,9 +121,7 @@ static int __tipc_sendmsg(struct socket *sock, struct msghdr *m, size_t dsz);
static const struct proto_ops packet_ops;
static const struct proto_ops stream_ops;
static const struct proto_ops msg_ops;
-
static struct proto tipc_proto;
-static struct proto tipc_proto_kern;
static const struct nla_policy tipc_nl_sock_policy[TIPC_NLA_SOCK_MAX + 1] = {
[TIPC_NLA_SOCK_UNSPEC] = { .type = NLA_UNSPEC },
@@ -341,11 +339,7 @@ static int tipc_sk_create(struct net *net, struct socket *sock,
}
/* Allocate socket's protocol area */
- if (!kern)
- sk = sk_alloc(net, AF_TIPC, GFP_KERNEL, &tipc_proto);
- else
- sk = sk_alloc(net, AF_TIPC, GFP_KERNEL, &tipc_proto_kern);
-
+ sk = sk_alloc(net, AF_TIPC, GFP_KERNEL, &tipc_proto);
if (sk == NULL)
return -ENOMEM;
@@ -383,75 +377,6 @@ static int tipc_sk_create(struct net *net, struct socket *sock,
return 0;
}
-/**
- * tipc_sock_create_local - create TIPC socket from inside TIPC module
- * @type: socket type - SOCK_RDM or SOCK_SEQPACKET
- *
- * We cannot use sock_creat_kern here because it bumps module user count.
- * Since socket owner and creator is the same module we must make sure
- * that module count remains zero for module local sockets, otherwise
- * we cannot do rmmod.
- *
- * Returns 0 on success, errno otherwise
- */
-int tipc_sock_create_local(struct net *net, int type, struct socket **res)
-{
- int rc;
-
- rc = sock_create_lite(AF_TIPC, type, 0, res);
- if (rc < 0) {
- pr_err("Failed to create kernel socket\n");
- return rc;
- }
- tipc_sk_create(net, *res, 0, 1);
-
- return 0;
-}
-
-/**
- * tipc_sock_release_local - release socket created by tipc_sock_create_local
- * @sock: the socket to be released.
- *
- * Module reference count is not incremented when such sockets are created,
- * so we must keep it from being decremented when they are released.
- */
-void tipc_sock_release_local(struct socket *sock)
-{
- tipc_release(sock);
- sock->ops = NULL;
- sock_release(sock);
-}
-
-/**
- * tipc_sock_accept_local - accept a connection on a socket created
- * with tipc_sock_create_local. Use this function to avoid that
- * module reference count is inadvertently incremented.
- *
- * @sock: the accepting socket
- * @newsock: reference to the new socket to be created
- * @flags: socket flags
- */
-
-int tipc_sock_accept_local(struct socket *sock, struct socket **newsock,
- int flags)
-{
- struct sock *sk = sock->sk;
- int ret;
-
- ret = sock_create_lite(sk->sk_family, sk->sk_type,
- sk->sk_protocol, newsock);
- if (ret < 0)
- return ret;
-
- ret = tipc_accept(sock, *newsock, flags);
- if (ret < 0) {
- sock_release(*newsock);
- return ret;
- }
- (*newsock)->ops = sock->ops;
- return ret;
-}
-
static void tipc_sk_callback(struct rcu_head *head)
{
struct tipc_sock *tsk = container_of(head, struct tipc_sock, rcu);
@@ -2608,12 +2533,6 @@ static struct proto tipc_proto = {
.sysctl_rmem = sysctl_tipc_rmem
};
-static struct proto tipc_proto_kern = {
- .name = "TIPC",
- .obj_size = sizeof(struct tipc_sock),
- .sysctl_rmem = sysctl_tipc_rmem
-};
-
/**
* tipc_socket_init - initialize TIPC socket interface
*
diff --git a/net/tipc/socket.h b/net/tipc/socket.h
index 238f1b7..bf65513 100644
--- a/net/tipc/socket.h
+++ b/net/tipc/socket.h
@@ -44,10 +44,6 @@
SKB_TRUESIZE(TIPC_MAX_USER_MSG_SIZE))
int tipc_socket_init(void);
void tipc_socket_stop(void);
-int tipc_sock_create_local(struct net *net, int type, struct socket **res);
-void tipc_sock_release_local(struct socket *sock);
-int tipc_sock_accept_local(struct socket *sock, struct socket **newsock,
- int flags);
int tipc_sk_rcv(struct net *net, struct sk_buff_head *inputq);
void tipc_sk_mcast_rcv(struct net *net, struct sk_buff_head *arrvq,
struct sk_buff_head *inputq);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH net-next 2/3] tipc: fix a potential deadlock when nametable is purged
2015-03-18 1:32 [PATCH net-next 0/3] tipc: fix netns refcnt leak Ying Xue
2015-03-18 1:32 ` [PATCH net-next 1/3] " Ying Xue
@ 2015-03-18 1:32 ` Ying Xue
2015-03-18 1:32 ` [PATCH net-next 3/3] tipc: withdraw tipc topology server name when namespace is deleted Ying Xue
2015-03-18 2:12 ` [PATCH net-next 0/3] tipc: fix netns refcnt leak David Miller
3 siblings, 0 replies; 5+ messages in thread
From: Ying Xue @ 2015-03-18 1:32 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, cwang, tipc-discussion, netdev
[ 28.531768] =============================================
[ 28.532322] [ INFO: possible recursive locking detected ]
[ 28.532322] 3.19.0+ #194 Not tainted
[ 28.532322] ---------------------------------------------
[ 28.532322] insmod/583 is trying to acquire lock:
[ 28.532322] (&(&nseq->lock)->rlock){+.....}, at: [<ffffffffa000d219>] tipc_nametbl_remove_publ+0x49/0x2e0 [tipc]
[ 28.532322]
[ 28.532322] but task is already holding lock:
[ 28.532322] (&(&nseq->lock)->rlock){+.....}, at: [<ffffffffa000e0dc>] tipc_nametbl_stop+0xfc/0x1f0 [tipc]
[ 28.532322]
[ 28.532322] other info that might help us debug this:
[ 28.532322] Possible unsafe locking scenario:
[ 28.532322]
[ 28.532322] CPU0
[ 28.532322] ----
[ 28.532322] lock(&(&nseq->lock)->rlock);
[ 28.532322] lock(&(&nseq->lock)->rlock);
[ 28.532322]
[ 28.532322] *** DEADLOCK ***
[ 28.532322]
[ 28.532322] May be due to missing lock nesting notation
[ 28.532322]
[ 28.532322] 3 locks held by insmod/583:
[ 28.532322] #0: (net_mutex){+.+.+.}, at: [<ffffffff8163e30f>] register_pernet_subsys+0x1f/0x50
[ 28.532322] #1: (&(&tn->nametbl_lock)->rlock){+.....}, at: [<ffffffffa000e091>] tipc_nametbl_stop+0xb1/0x1f0 [tipc]
[ 28.532322] #2: (&(&nseq->lock)->rlock){+.....}, at: [<ffffffffa000e0dc>] tipc_nametbl_stop+0xfc/0x1f0 [tipc]
[ 28.532322]
[ 28.532322] stack backtrace:
[ 28.532322] CPU: 1 PID: 583 Comm: insmod Not tainted 3.19.0+ #194
[ 28.532322] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 28.532322] ffffffff82394460 ffff8800144cb928 ffffffff81792f3e 0000000000000007
[ 28.532322] ffffffff82394460 ffff8800144cba28 ffffffff810a8080 ffff8800144cb998
[ 28.532322] ffffffff810a4df3 ffff880013e9cb10 ffffffff82b0d330 ffff880013e9cb38
[ 28.532322] Call Trace:
[ 28.532322] [<ffffffff81792f3e>] dump_stack+0x4c/0x65
[ 28.532322] [<ffffffff810a8080>] __lock_acquire+0x740/0x1ca0
[ 28.532322] [<ffffffff810a4df3>] ? __bfs+0x23/0x270
[ 28.532322] [<ffffffff810a7506>] ? check_irq_usage+0x96/0xe0
[ 28.532322] [<ffffffff810a8a73>] ? __lock_acquire+0x1133/0x1ca0
[ 28.532322] [<ffffffffa000d219>] ? tipc_nametbl_remove_publ+0x49/0x2e0 [tipc]
[ 28.532322] [<ffffffff810a9c0c>] lock_acquire+0x9c/0x140
[ 28.532322] [<ffffffffa000d219>] ? tipc_nametbl_remove_publ+0x49/0x2e0 [tipc]
[ 28.532322] [<ffffffff8179c41f>] _raw_spin_lock_bh+0x3f/0x50
[ 28.532322] [<ffffffffa000d219>] ? tipc_nametbl_remove_publ+0x49/0x2e0 [tipc]
[ 28.532322] [<ffffffffa000d219>] tipc_nametbl_remove_publ+0x49/0x2e0 [tipc]
[ 28.532322] [<ffffffffa000e11e>] tipc_nametbl_stop+0x13e/0x1f0 [tipc]
[ 28.532322] [<ffffffffa000dfe5>] ? tipc_nametbl_stop+0x5/0x1f0 [tipc]
[ 28.532322] [<ffffffffa0004bab>] tipc_init_net+0x13b/0x150 [tipc]
[ 28.532322] [<ffffffffa0004a75>] ? tipc_init_net+0x5/0x150 [tipc]
[ 28.532322] [<ffffffff8163dece>] ops_init+0x4e/0x150
[ 28.532322] [<ffffffff810aa66d>] ? trace_hardirqs_on+0xd/0x10
[ 28.532322] [<ffffffff8163e1d3>] register_pernet_operations+0xf3/0x190
[ 28.532322] [<ffffffff8163e31e>] register_pernet_subsys+0x2e/0x50
[ 28.532322] [<ffffffffa002406a>] tipc_init+0x6a/0x1000 [tipc]
[ 28.532322] [<ffffffffa0024000>] ? 0xffffffffa0024000
[ 28.532322] [<ffffffff810002d9>] do_one_initcall+0x89/0x1c0
[ 28.532322] [<ffffffff811b7cb0>] ? kmem_cache_alloc_trace+0x50/0x1b0
[ 28.532322] [<ffffffff810e725b>] ? do_init_module+0x2b/0x200
[ 28.532322] [<ffffffff810e7294>] do_init_module+0x64/0x200
[ 28.532322] [<ffffffff810e9353>] load_module+0x12f3/0x18e0
[ 28.532322] [<ffffffff810e5890>] ? show_initstate+0x50/0x50
[ 28.532322] [<ffffffff810e9a19>] SyS_init_module+0xd9/0x110
[ 28.532322] [<ffffffff8179f3b3>] sysenter_dispatch+0x7/0x1f
Before tipc_purge_publications() calls tipc_nametbl_remove_publ() to
remove a publication with a name sequence, the name sequence's lock
is held. However, when tipc_nametbl_remove_publ() calling
tipc_nameseq_remove_publ() to remove the publication, it first tries
to query name sequence instance with the publication, and then holds
the lock of the found name sequence. But as the lock may be already
taken in tipc_purge_publications(), deadlock happens like above
scenario demonstrated. As tipc_nameseq_remove_publ() doesn't grab name
sequence's lock, the deadlock can be avoided if it's directly invoked
by tipc_purge_publications().
Fixes: 97ede29e80ee ("tipc: convert name table read-write lock to RCU")
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/name_table.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index 105ba7ad..ab0ac62 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -811,8 +811,8 @@ static void tipc_purge_publications(struct net *net, struct name_seq *seq)
sseq = seq->sseqs;
info = sseq->info;
list_for_each_entry_safe(publ, safe, &info->zone_list, zone_list) {
- tipc_nametbl_remove_publ(net, publ->type, publ->lower,
- publ->node, publ->ref, publ->key);
+ tipc_nameseq_remove_publ(net, seq, publ->lower, publ->node,
+ publ->ref, publ->key);
kfree_rcu(publ, rcu);
}
hlist_del_init_rcu(&seq->ns_list);
--
1.7.9.5
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH net-next 3/3] tipc: withdraw tipc topology server name when namespace is deleted
2015-03-18 1:32 [PATCH net-next 0/3] tipc: fix netns refcnt leak Ying Xue
2015-03-18 1:32 ` [PATCH net-next 1/3] " Ying Xue
2015-03-18 1:32 ` [PATCH net-next 2/3] tipc: fix a potential deadlock when nametable is purged Ying Xue
@ 2015-03-18 1:32 ` Ying Xue
2015-03-18 2:12 ` [PATCH net-next 0/3] tipc: fix netns refcnt leak David Miller
3 siblings, 0 replies; 5+ messages in thread
From: Ying Xue @ 2015-03-18 1:32 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, cwang, erik.hugne, netdev, tipc-discussion
The TIPC topology server is a per namespace service associated with the
tipc name {1, 1}. When a namespace is deleted, that name must be withdrawn
before we call sk_release_kernel because the kernel socket release is
done in init_net and trying to withdraw a TIPC name published in another
namespace will fail with an error as:
[ 170.093264] Unable to remove local publication
[ 170.093264] (type=1, lower=1, ref=2184244004, key=2184244005)
We fix this by breaking the association between the topology server name
and socket before calling sk_release_kernel.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/server.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/tipc/server.c b/net/tipc/server.c
index a57c840..ab6183c 100644
--- a/net/tipc/server.c
+++ b/net/tipc/server.c
@@ -90,6 +90,7 @@ static void tipc_clean_outqueues(struct tipc_conn *con);
static void tipc_conn_kref_release(struct kref *kref)
{
struct tipc_conn *con = container_of(kref, struct tipc_conn, kref);
+ struct sockaddr_tipc *saddr = con->server->saddr;
struct socket *sock = con->sock;
struct sock *sk;
@@ -99,6 +100,8 @@ static void tipc_conn_kref_release(struct kref *kref)
__module_get(sock->ops->owner);
__module_get(sk->sk_prot_creator->owner);
}
+ saddr->scope = -TIPC_NODE_SCOPE;
+ kernel_bind(sock, (struct sockaddr *)saddr, sizeof(*saddr));
sk_release_kernel(sk);
con->sock = NULL;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH net-next 0/3] tipc: fix netns refcnt leak
2015-03-18 1:32 [PATCH net-next 0/3] tipc: fix netns refcnt leak Ying Xue
` (2 preceding siblings ...)
2015-03-18 1:32 ` [PATCH net-next 3/3] tipc: withdraw tipc topology server name when namespace is deleted Ying Xue
@ 2015-03-18 2:12 ` David Miller
3 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2015-03-18 2:12 UTC (permalink / raw)
To: ying.xue; +Cc: jon.maloy, cwang, erik.hugne, netdev, tipc-discussion
From: Ying Xue <ying.xue@windriver.com>
Date: Wed, 18 Mar 2015 09:32:56 +0800
> The series aims to eliminate the issue of netns refcount leak. But
> during fixing it, another two additional problems are found. So all
> of known issues associated with the netns refcnt leak are resolved
> at the same time in the patchset.
Series applied, thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-03-18 2:12 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-18 1:32 [PATCH net-next 0/3] tipc: fix netns refcnt leak Ying Xue
2015-03-18 1:32 ` [PATCH net-next 1/3] " Ying Xue
2015-03-18 1:32 ` [PATCH net-next 2/3] tipc: fix a potential deadlock when nametable is purged Ying Xue
2015-03-18 1:32 ` [PATCH net-next 3/3] tipc: withdraw tipc topology server name when namespace is deleted Ying Xue
2015-03-18 2:12 ` [PATCH net-next 0/3] tipc: fix netns refcnt leak David Miller
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).