]> asedeno.scripts.mit.edu Git - linux.git/commit
Merge branch 'kernel_socket_netns'
authorDavid S. Miller <davem@davemloft.net>
Mon, 11 May 2015 14:50:19 +0000 (10:50 -0400)
committerDavid S. Miller <davem@davemloft.net>
Mon, 11 May 2015 14:50:19 +0000 (10:50 -0400)
commit0198e09c4bdd7bce00c451c51a86a239c356a315
tree0f787a635911a4c854638de7ff36cb93a32ca5aa
parent80ba92fa1a92dea128283f69f55b02242e213650
parentaffb9792f1d99e1e4d64411e147b648d65f2576e
Merge branch 'kernel_socket_netns'

Eric W. Biederman says:

====================
Cleanup the kernel sockets.

Right now the situtation for allocating kernel sockets is a mess.
- sock_create_kern does not take a namespace parameter.
- kernel sockets must not reference count a network namespace and keep
  it alive or else we will have a reference counting loop.
- The way we avoid the reference counting loop with sk_change_net
  and sk_release_kernel are major hacks.

This patchset addresses this mess by fixing sock_create_kern to do
everything necessary to create a kernel socket.  None of the current
users of kernel sockets need the network namespace reference counted.
Either kernel sockets are network namespace aware (and using the current
hacks) or kernel sockets are limited to the initial network namespace
in which case it does not matter.

This patchset starts by addressing tun which should be using normal
userspace sockets like macvtap.

Then sock_create_kern is fixed to take a network namespace.
Then the in kernel status of sockets are passed through to sk_alloc.
Then sk_alloc is fixed to not reference count the network namespace
     of kernel sockets.
Then the callers of sock_create_kern are fixed up to stop using hacks.
Then netlink which uses it's own flavor of sock_create_kern is fixed.

Finally the hacks that are sk_change_net and sk_release_kernel are removed.

When it is all done the code is easier to follow, easier to use, easier
to maintain and shorter by about 70 lines.
====================

Reported-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>