netdev - Re: [PATCH net-next] pkt_sched: namespace aware ifb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130113145929.GK5259@kvack.org>
Date:	Sun, 13 Jan 2013 09:59:29 -0500
From:	Benjamin LaHaise <bcrl@...ck.org>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>, socketcan@...tkopp.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] pkt_sched: namespace aware ifb

On Sat, Jan 12, 2013 at 09:49:59PM -0800, Eric Dumazet wrote:
> But it is working in my tests.
> 
> I added a WARN and the call stack is :
...
> Could you elaborate on what could be the problem ?
> 
> We hold the RTNL, so I dont think another process could possibly call
> tcf_mirred_init()

The locking isn't the issue, but how the network namespace is selected it.  
I've implemented some virtual router functionality using network namespaces, 
and prior to having the setns() syscall, the only way to manipulate other 
network namespaces was via socket passing between threads in different 
namespaces.  One of the optimizations in using this technique was to open a 
netlink socket in another namespace, then pass that file descriptor back to 
the main daemon.  The code could then add routes and manipulate other areas 
of the network stack via that netlink socket.

I think this technique is a valid approach for making use of network 
namespaces.  It also has the benefit of avoid the use of setns() for the 
vast majority of operations.

		-ben
-- 
"Thought is the essence of where you are now."
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html