snowball/igloo-kernel.git/net/core, branch u0

lttng-instrumentation-net-fix-conflict

2011-03-16T23:05:59+00:00

lttng instrumentation net fix conflict Signed-off-by: Mathieu Desnoyers

lttng-instrumentation-net-move-network-tracepoints

2011-03-16T23:05:27+00:00

LTTng instrumentation net: move network tracepoints One of the objectives when tracing the network subsystems is to trace packet emission as late as possible and packet arrival as soon as possible in order to have more accurate timing measurements. This patch moves the xmit tracepoint to the dev_hard_start_xmit() function, the last function called that is not network interface specific but is called for every frame. The tracepoint is also duplicated to trace each segmented packet when GSO is in effect. The receive tracepoint is moved earlier in the netif_receive_skb() function. The tracepoint is also duplicated in the netif_rx() function. This enables more precise measurements for pre-NAPI drivers. Signed-off-by: Benjamin Poirier Signed-off-by: Mathieu Desnoyers

lttng-instrumentation/lttng-instrumentation-net

2011-03-16T23:04:36+00:00

LTTng instrumentation - net Network device activity instrumentation (xmit/receive). Allows to detect when a packet had arrived on the network card or when it is going to be sent. This is the instrumentation point outside of the drivers that is the closest to the hardware. It allows to detect the amount of time taken by a packet to go through the kernel between the system call and the actual delivery to the network card (given that system calls are instrumented). Those tracepoints are used by LTTng. About the performance impact of tracepoints (which is comparable to markers), even without immediate values optimizations, tests done by Hideo Aoki on ia64 show no regression. His test case was using hackbench on a kernel where scheduler instrumentation (about 5 events in code scheduler code) was added. See the "Tracepoints" patch header for performance result detail. 2.6.29-rc : now instrument __napi_complete rather than napi_complete wrapper. Note about 2.6.31: napi_poll instrumentation is before the poll, while mainline instrumentation is after poll. Leaving both for now. Signed-off-by: Mathieu Desnoyers CC: Andrew Morton CC: netdev@vger.kernel.org CC: Jeff Garzik CC: Masami Hiramatsu CC: 'Peter Zijlstra' CC: "Frank Ch. Eigler" CC: 'Ingo Molnar' CC: 'Hideo AOKI' CC: Takashi Nishiie CC: 'Steven Rostedt' CC: Eduard - Gabriel Munteanu

Merge branch 'master' of /home/davem/src/GIT/linux-2.6/

2011-03-10T22:00:44+00:00

net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules

2011-03-09T23:25:19+00:00

Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c any process with CAP_NET_ADMIN may load any module from /lib/modules/. This doesn't mean that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are limited to /lib/modules/**. However, CAP_NET_ADMIN capability shouldn't allow anybody load any module not related to networking. This patch restricts an ability of autoloading modules to netdev modules with explicit aliases. This fixes CVE-2011-1019. Arnd Bergmann suggested to leave untouched the old pre-v2.6.32 behavior of loading netdev modules by name (without any prefix) for processes with CAP_SYS_MODULE to maintain the compatibility with network scripts that use autoloading netdev modules by aliases like "eth0", "wlan0". Currently there are only three users of the feature in the upstream kernel: ipip, ip_gre and sit. root@albatros:~# capsh --drop=$(seq -s, 0 11),$(seq -s, 13 34) -- root@albatros:~# grep Cap /proc/$$/status CapInh: 0000000000000000 CapPrm: fffffff800001000 CapEff: fffffff800001000 CapBnd: fffffff800001000 root@albatros:~# modprobe xfs FATAL: Error inserting xfs (/lib/modules/2.6.38-rc6-00001-g2bf4ca3/kernel/fs/xfs/xfs.ko): Operation not permitted root@albatros:~# lsmod | grep xfs root@albatros:~# ifconfig xfs xfs: error fetching interface information: Device not found root@albatros:~# lsmod | grep xfs root@albatros:~# lsmod | grep sit root@albatros:~# ifconfig sit sit: error fetching interface information: Device not found root@albatros:~# lsmod | grep sit root@albatros:~# ifconfig sit0 sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 root@albatros:~# lsmod | grep sit sit 10457 0 tunnel4 2957 1 sit For CAP_SYS_MODULE module loading is still relaxed: root@albatros:~# grep Cap /proc/$$/status CapInh: 0000000000000000 CapPrm: ffffffffffffffff CapEff: ffffffffffffffff CapBnd: ffffffffffffffff root@albatros:~# ifconfig xfs xfs: error fetching interface information: Device not found root@albatros:~# lsmod | grep xfs xfs 745319 0 Reference: https://lkml.org/lkml/2011/2/24/203 Signed-off-by: Vasiliy Kulikov Signed-off-by: Michael Tokarev Acked-by: David S. Miller Acked-by: Kees Cook Signed-off-by: James Morris

pktgen: fix errata in show results

2011-03-09T22:11:00+00:00

The units in show_results in pktgen were not correct. The results are in usec but it was displayed nsec. Reported-by: Jong-won Lee Signed-off-by: Daniel Turull Signed-off-by: David S. Miller

net: handle addr_type of 0 properly

2011-02-25T21:58:54+00:00

addr_type of 0 means that the type should be adopted from from_dev and not from __hw_addr_del_multiple(). Unfortunately it isn't so and addr_type will always be considered. Fix this by implementing the considered and documented behavior. Signed-off-by: Hagen Paul Pfeifer Signed-off-by: David S. Miller

net: deinit automatic LIST_HEAD

2011-02-18T19:49:36+00:00

commit 9b5e383c11b08784 (net: Introduce unregister_netdevice_many()) left an active LIST_HEAD() in rollback_registered(), with possible memory corruption. Even if device is freed without touching its unreg_list (and therefore touching the previous memory location holding LISTE_HEAD(single), better close the bug for good, since its really subtle. (Same fix for default_device_exit_batch() for completeness) Reported-by: Michal Hocko Tested-by: Michal Hocko Reported-by: Eric W. Biderman Tested-by: Eric W. Biderman Signed-off-by: Linus Torvalds Signed-off-by: Eric Dumazet CC: Ingo Molnar CC: Octavian Purdila CC: stable [.33+] Signed-off-by: David S. Miller

net: dont leave active on stack LIST_HEAD

2011-02-18T19:49:35+00:00

Eric W. Biderman and Michal Hocko reported various memory corruptions that we suspected to be related to a LIST head located on stack, that was manipulated after thread left function frame (and eventually exited, so its stack was freed and reused). Eric Dumazet suggested the problem was probably coming from commit 443457242beb (net: factorize sync-rcu call in unregister_netdevice_many) This patch fixes __dev_close() and dev_close() to properly deinit their respective LIST_HEAD(single) before exiting. References: https://lkml.org/lkml/2011/2/16/304 References: https://lkml.org/lkml/2011/2/14/223 Reported-by: Michal Hocko Tested-by: Michal Hocko Reported-by: Eric W. Biderman Tested-by: Eric W. Biderman Signed-off-by: Linus Torvalds Signed-off-by: Eric Dumazet CC: Ingo Molnar CC: Octavian Purdila Signed-off-by: David S. Miller

net: Fix lockdep regression caused by initializing netdev queues too early.

2011-02-08T23:02:50+00:00

In commit aa9421041128abb4d269ee1dc502ff65fb3b7d69 ("net: init ingress queue") we moved the allocation and lock initialization of the queues into alloc_netdev_mq() since register_netdevice() is way too late. The problem is that dev->type is not setup until the setup() callback is invoked by alloc_netdev_mq(), and the dev->type is what determines the lockdep class to use for the locks in the queues. Fix this by doing the queue allocation after the setup() callback runs. This is safe because the setup() callback is not allowed to make any state changes that need to be undone on error (memory allocations, etc.). It may, however, make state changes that are undone by free_netdev() (such as netif_napi_add(), which is done by the ipoib driver's setup routine). The previous code also leaked a reference to the &init_net namespace object on RX/TX queue allocation failures. Signed-off-by: David S. Miller