linux-stable.git/net/core/sysctl_net_core.c, branch v3.9

net: avoid to hang up on sending due to sysctl configuration overflow.

2013-01-29T04:15:27+00:00

    I found if we write a larger than 4GB value to some sysctl
variables, the sending syscall will hang up forever, because these
variables are 32 bits, such large values make them overflow to 0 or
negative.

    This patch try to fix overflow or prevent from zero value setup
of below sysctl variables:

net.core.wmem_default
net.core.rmem_default

net.core.rmem_max
net.core.wmem_max

net.ipv4.udp_rmem_min
net.ipv4.udp_wmem_min

net.ipv4.tcp_wmem
net.ipv4.tcp_rmem

Signed-off-by: Eric Dumazet 
Signed-off-by: Li Yu 
Signed-off-by: David S. Miller

net: Don't export sysctls to unprivileged users

2012-11-19T01:30:55+00:00

In preparation for supporting the creation of network namespaces
by unprivileged users, modify all of the per net sysctl exports
and refuse to allow them to unprivileged users.

This makes it safe for unprivileged users in general to access
per net sysctls, and allows sysctls to be exported to unprivileged
users on an individual basis as they are deemed safe.

Signed-off-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller

net: Delete all remaining instances of ctl_path

2012-04-21T01:22:30+00:00

We don't use struct ctl_path anymore so delete the exported constants.

Signed-off-by: Eric W. Biederman 
Acked-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

net: Convert all sysctl registrations to register_net_sysctl

2012-04-21T01:22:30+00:00

This results in code with less boiler plate that is a bit easier
to read.

Additionally stops us from using compatibility code in the sysctl
core, hastening the day when the compatibility code can be removed.

Signed-off-by: Eric W. Biederman 
Acked-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

net core: Remove unneded creation of an empty net/core sysctl directory

2012-04-21T01:21:18+00:00

On the next line we register the net_core_table in net/core which
creates the directory and ensures it exists.

Signed-off-by: Eric W. Biederman 
Acked-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

net: Move all of the network sysctls without a namespace into init_net.

2012-04-21T01:21:17+00:00

This makes it clearer which sysctls are relative to your current network
namespace.

This makes it a little less error prone by not exposing sysctls for the
initial network namespace in other namespaces.

This is the same way we handle all of our other network interfaces to
userspace and I can't honestly remember why we didn't do this for
sysctls right from the start.

Signed-off-by: Eric W. Biederman 
Acked-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

net: Kill register_sysctl_rotable

2012-04-21T01:21:17+00:00

register_sysctl_rotable never caught on as an interesting way to
register sysctls.  My take on the situation is that what we want are
sysctls that we can only see in the initial network namespace.  What we
have implemented with register_sysctl_rotable are sysctls that we can
see in all of the network namespaces and can only change in the initial
network namespace.

That is a very silly way to go.  Just register the network sysctls
in the initial network namespace and we don't have any weird special
cases to deal with.

The sysctls affected are:
/proc/sys/net/ipv4/ipfrag_secret_interval
/proc/sys/net/ipv4/ipfrag_max_dist
/proc/sys/net/ipv6/ip6frag_secret_interval
/proc/sys/net/ipv6/mld_max_msf

I really don't expect anyone will miss them if they can't read them in a
child user namespace.

CC: Pavel Emelyanov 
Signed-off-by: Eric W. Biederman 
Acked-by: Pavel Emelyanov 
Signed-off-by: David S. Miller

net: fix compile error of leaking kmemleak.h header

2012-04-19T04:11:39+00:00

net/core/sysctl_net_core.c: In function ‘sysctl_core_init’:
net/core/sysctl_net_core.c:259: error: implicit declaration of function ‘kmemleak_not_leak’

with same error in net/ipv4/route.c

Signed-off-by: Shan Wei 
Signed-off-by: David S. Miller

net/core:Remove memleak reports by kmemleak_not_leak.

2012-04-18T04:20:28+00:00

Signed-off-by: majianpeng 
Signed-off-by: David S. Miller

static keys: Introduce 'struct static_key', static_key_true()/false() and static_key_slow_[inc|dec]()

2012-02-24T09:05:59+00:00

So here's a boot tested patch on top of Jason's series that does
all the cleanups I talked about and turns jump labels into a
more intuitive to use facility. It should also address the
various misconceptions and confusions that surround jump labels.

Typical usage scenarios:

        #include 

        struct static_key key = STATIC_KEY_INIT_TRUE;

        if (static_key_false(&key))
                do unlikely code
        else
                do likely code

Or:

        if (static_key_true(&key))
                do likely code
        else
                do unlikely code

The static key is modified via:

        static_key_slow_inc(&key);
        ...
        static_key_slow_dec(&key);

The 'slow' prefix makes it abundantly clear that this is an
expensive operation.

I've updated all in-kernel code to use this everywhere. Note
that I (intentionally) have not pushed through the rename
blindly through to the lowest levels: the actual jump-label
patching arch facility should be named like that, so we want to
decouple jump labels from the static-key facility a bit.

On non-jump-label enabled architectures static keys default to
likely()/unlikely() branches.

Signed-off-by: Ingo Molnar 
Acked-by: Jason Baron 
Acked-by: Steven Rostedt 
Cc: a.p.zijlstra@chello.nl
Cc: mathieu.desnoyers@efficios.com
Cc: davem@davemloft.net
Cc: ddaney.cavm@gmail.com
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/20120222085809.GA26397@elte.hu
Signed-off-by: Ingo Molnar