linux/include/net, branch v3.4.7

bonding: Fix corrupted queue_mapping

2012-07-16T16:03:47Z

[ Upstream commit 5ee31c6898ea5537fcea160999d60dc63bc0c305 ] In the transmit path of the bonding driver, skb->cb is used to stash the skb->queue_mapping so that the bonding device can set its own queue mapping. This value becomes corrupted since the skb->cb is also used in __dev_xmit_skb. When transmitting through bonding driver, bond_select_queue is called from dev_queue_xmit. In bond_select_queue the original skb->queue_mapping is copied into skb->cb (via bond_queue_mapping) and skb->queue_mapping is overwritten with the bond driver queue. Subsequently in dev_queue_xmit, __dev_xmit_skb is called which writes the packet length into skb->cb, thereby overwriting the stashed queue mappping. In bond_dev_queue_xmit (called from hard_start_xmit), the queue mapping for the skb is set to the stashed value which is now the skb length and hence is an invalid queue for the slave device. If we want to save skb->queue_mapping into skb->cb[], best place is to add a field in struct qdisc_skb_cb, to make sure it wont conflict with other layers (eg : Qdiscc, Infiniband...) This patchs also makes sure (struct qdisc_skb_cb)->data is aligned on 8 bytes : netem qdisc for example assumes it can store an u64 in it, without misalignment penalty. Note : we only have 20 bytes left in (struct qdisc_skb_cb)->data[]. The largest user is CHOKe and it fills it. Based on a previous patch from Tom Herbert. Signed-off-by: Eric Dumazet Reported-by: Tom Herbert Cc: John Fastabend Cc: Roland Dreier Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

inetpeer: fix a race in inetpeer_gc_worker()

2012-07-16T16:03:45Z

[ Upstream commit 55432d2b543a4b6dfae54f5c432a566877a85d90 ] commit 5faa5df1fa2024 (inetpeer: Invalidate the inetpeer tree along with the routing cache) added a race : Before freeing an inetpeer, we must respect a RCU grace period, and make sure no user will attempt to increase refcnt. inetpeer_invalidate_tree() waits for a RCU grace period before inserting inetpeer tree into gc_list and waking the worker. At that time, no concurrent lookup can find a inetpeer in this tree. Signed-off-by: Eric Dumazet Cc: Steffen Klassert Acked-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

cipso: handle CIPSO options correctly when NetLabel is disabled

2012-07-16T16:03:44Z

[ Upstream commit 20e2a86485967c385d7c7befc1646e4d1d39362e ] When NetLabel is not enabled, e.g. CONFIG_NETLABEL=n, and the system receives a CIPSO tagged packet it is dropped (cipso_v4_validate() returns non-zero). In most cases this is the correct and desired behavior, however, in the case where we are simply forwarding the traffic, e.g. acting as a network bridge, this becomes a problem. This patch fixes the forwarding problem by providing the basic CIPSO validation code directly in ip_options_compile() without the need for the NetLabel or CIPSO code. The new validation code can not perform any of the CIPSO option label/value verification that cipso_v4_validate() does, but it can verify the basic CIPSO option format. The behavior when NetLabel is enabled is unchanged. Signed-off-by: Paul Moore Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ipv6: fix incorrect ipsec fragment

2012-06-09T15:36:15Z

[ Upstream commit 0c1833797a5a6ec23ea9261d979aa18078720b74 ] Since commit ad0081e43a "ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed" the fragment of packets is incorrect. because tunnel mode needs IPsec headers and trailer for all fragments, while on transport mode it is sufficient to add the headers to the first fragment and the trailer to the last. so modify mtu and maxfraglen base on ipsec mode and if fragment is first or last. with my test,it work well(every fragment's size is the mtu) and does not trigger slow fragment path. Changes from v1: though optimization, mtu_prev and maxfraglen_prev can be delete. replace xfrm mode codes with dst_entry's new frag DST_XFRM_TUNNEL. add fuction ip6_append_data_mtu to make codes clearer. Signed-off-by: Gao feng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem

2012-05-15T20:38:00Z

Bluetooth: notify userspace of security level change

2012-05-14T17:51:25Z

It fixes L2CAP socket based security level elevation during a connection. The HID profile needs this (for keyboards) and it is the only way to achieve the security level elevation when using the management interface to talk to the kernel (hence the management enabling patch being the one that exposes this issue). It enables the userspace a security level change when the socket is already connected and create a way to notify the socket the result of the request. At the moment of the request the socket is made non writable, if the request fails the connections closes, otherwise the socket is made writable again, POLL_OUT is emmited. Signed-off-by: Gustavo Padovan Acked-by: Marcel Holtmann Signed-off-by: Johan Hedberg Signed-off-by: John W. Linville

sctp: check cached dst before using it

2012-05-11T03:15:47Z

dst_check() will take care of SA (and obsolete field), hence IPsec rekeying scenario is taken into account. Signed-off-by: Nicolas Dichtel Acked-by: Vlad Yaseivch Signed-off-by: David S. Miller

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem

2012-05-01T18:14:05Z

net: fix sk_sockets_allocated_read_positive

2012-04-30T17:37:59Z

Denys Fedoryshchenko reported frequent crashes on a proxy server and kindly provided a lockdep report that explains it all : [ 762.903868] [ 762.903880] ================================= [ 762.903890] [ INFO: inconsistent lock state ] [ 762.903903] 3.3.4-build-0061 #8 Not tainted [ 762.904133] --------------------------------- [ 762.904344] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. [ 762.904542] squid/1603 [HC0[0]:SC0[0]:HE1:SE1] takes: [ 762.904542] (key#3){+.?...}, at: [] __percpu_counter_sum+0xd/0x58 [ 762.904542] {IN-SOFTIRQ-W} state was registered at: [ 762.904542] [] __lock_acquire+0x284/0xc26 [ 762.904542] [] lock_acquire+0x71/0x85 [ 762.904542] [] _raw_spin_lock+0x33/0x40 [ 762.904542] [] __percpu_counter_add+0x58/0x7c [ 762.904542] [] sk_clone_lock+0x1e5/0x200 [ 762.904542] [] inet_csk_clone_lock+0xe/0x78 [ 762.904542] [] tcp_create_openreq_child+0x1b/0x404 [ 762.904542] [] tcp_v4_syn_recv_sock+0x32/0x1c1 [ 762.904542] [] tcp_check_req+0x1fd/0x2d7 [ 762.904542] [] tcp_v4_do_rcv+0xab/0x194 [ 762.904542] [] tcp_v4_rcv+0x3b3/0x5cc [ 762.904542] [] ip_local_deliver_finish+0x13a/0x1e9 [ 762.904542] [] NF_HOOK.clone.11+0x46/0x4d [ 762.904542] [] ip_local_deliver+0x41/0x45 [ 762.904542] [] ip_rcv_finish+0x31a/0x33c [ 762.904542] [] NF_HOOK.clone.11+0x46/0x4d [ 762.904542] [] ip_rcv+0x201/0x23e [ 762.904542] [] __netif_receive_skb+0x319/0x368 [ 762.904542] [] netif_receive_skb+0x4e/0x7d [ 762.904542] [] napi_skb_finish+0x1e/0x34 [ 762.904542] [] napi_gro_receive+0x20/0x24 [ 762.904542] [] e1000_receive_skb+0x3f/0x45 [e1000e] [ 762.904542] [] e1000_clean_rx_irq+0x1f9/0x284 [e1000e] [ 762.904542] [] e1000_clean+0x62/0x1f4 [e1000e] [ 762.904542] [] net_rx_action+0x90/0x160 [ 762.904542] [] __do_softirq+0x7b/0x118 [ 762.904542] irq event stamp: 156915469 [ 762.904542] hardirqs last enabled at (156915469): [] __slab_alloc.clone.58.clone.63+0xc4/0x2de [ 762.904542] hardirqs last disabled at (156915468): [] __slab_alloc.clone.58.clone.63+0x22/0x2de [ 762.904542] softirqs last enabled at (156915466): [] lock_sock_nested+0x64/0x6c [ 762.904542] softirqs last disabled at (156915464): [] _raw_spin_lock_bh+0xe/0x45 [ 762.904542] [ 762.904542] other info that might help us debug this: [ 762.904542] Possible unsafe locking scenario: [ 762.904542] [ 762.904542] CPU0 [ 762.904542] ---- [ 762.904542] lock(key#3); [ 762.904542] [ 762.904542] lock(key#3); [ 762.904542] [ 762.904542] *** DEADLOCK *** [ 762.904542] [ 762.904542] 1 lock held by squid/1603: [ 762.904542] #0: (sk_lock-AF_INET){+.+.+.}, at: [] lock_sock+0xa/0xc [ 762.904542] [ 762.904542] stack backtrace: [ 762.904542] Pid: 1603, comm: squid Not tainted 3.3.4-build-0061 #8 [ 762.904542] Call Trace: [ 762.904542] [] ? printk+0x18/0x1d [ 762.904542] [] valid_state+0x1f6/0x201 [ 762.904542] [] mark_lock+0xd1/0x1bb [ 762.904542] [] ? mark_lock+0x26/0x1bb [ 762.904542] [] ? check_usage_forwards+0x77/0x77 [ 762.904542] [] __lock_acquire+0x2f8/0xc26 [ 762.904542] [] ? mark_held_locks+0x5d/0x7b [ 762.904542] [] ? trace_hardirqs_on+0xb/0xd [ 762.904542] [] ? __lock_acquire+0x4d4/0xc26 [ 762.904542] [] lock_acquire+0x71/0x85 [ 762.904542] [] ? __percpu_counter_sum+0xd/0x58 [ 762.904542] [] _raw_spin_lock+0x33/0x40 [ 762.904542] [] ? __percpu_counter_sum+0xd/0x58 [ 762.904542] [] __percpu_counter_sum+0xd/0x58 [ 762.904542] [] __sk_mem_schedule+0xdd/0x1c7 [ 762.904542] [] ? __alloc_skb+0x76/0x100 [ 762.904542] [] sk_wmem_schedule+0x21/0x2d [ 762.904542] [] sk_stream_alloc_skb+0x42/0xaa [ 762.904542] [] tcp_sendmsg+0x18f/0x68b [ 762.904542] [] ? ip_fast_csum+0x30/0x30 [ 762.904542] [] inet_sendmsg+0x53/0x5a [ 762.904542] [] sock_aio_write+0xd2/0xda [ 762.904542] [] ? mark_lock+0x26/0x1bb [ 762.904542] [] do_sync_write+0x9f/0xd9 [ 762.904542] [] ? file_free_rcu+0x2f/0x2f [ 762.904542] [] vfs_write+0x8f/0xab [ 762.904542] [] ? fget_light+0x75/0x7c [ 762.904542] [] sys_write+0x3d/0x5e [ 762.904542] [] syscall_call+0x7/0xb [ 762.904542] [] ? rp_sidt+0x41/0x83 Bug is that sk_sockets_allocated_read_positive() calls percpu_counter_sum_positive() without BH being disabled. This bug was added in commit 180d8cd942ce33 (foundations of per-cgroup memory pressure controlling.), since previous code was using percpu_counter_read_positive() which is IRQ safe. In __sk_mem_schedule() we dont need the precise count of allocated sockets and can revert to previous behavior. Reported-by: Denys Fedoryshchenko Sined-off-by: Eric Dumazet Cc: Glauber Costa Acked-by: Neal Cardwell Signed-off-by: David S. Miller

Merge branch 'master' of git://1984.lsi.us.es/net

2012-04-30T17:23:22Z