linux-toradex.git/net, branch v3.2.5

tcp: md5: using remote adress for md5 lookup in rst packet

2012-02-03T17:22:21+00:00

[ Upstream commit 8a622e71f58ec9f092fc99eacae0e6cf14f6e742 ]

md5 key is added in socket through remote address.
remote address should be used in finding md5 key when
sending out reset packet.

Signed-off-by: shawnlu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: fix tcp_trim_head() to adjust segment count with skb MSS

2012-02-03T17:22:21+00:00

[ Upstream commit 5b35e1e6e9ca651e6b291c96d1106043c9af314a ]

This commit fixes tcp_trim_head() to recalculate the number of
segments in the skb with the skb's existing MSS, so trimming the head
causes the skb segment count to be monotonically non-increasing - it
should stay the same or go down, but not increase.

Previously tcp_trim_head() used the current MSS of the connection. But
if there was a decrease in MSS between original transmission and ACK
(e.g. due to PMTUD), this could cause tcp_trim_head() to
counter-intuitively increase the segment count when trimming bytes off
the head of an skb. This violated assumptions in tcp_tso_acked() that
tcp_trim_head() only decreases the packet count, so that packets_acked
in tcp_tso_acked() could underflow, leading tcp_clean_rtx_queue() to
pass u32 pkts_acked values as large as 0xffffffff to
ca_ops->pkts_acked().

As an aside, if tcp_trim_head() had really wanted the skb to reflect
the current MSS, it should have called tcp_set_skb_tso_segs()
unconditionally, since a decrease in MSS would mean that a
single-packet skb should now be sliced into multiple segments.

Signed-off-by: Neal Cardwell 
Acked-by: Nandita Dukkipati 
Acked-by: Ilpo Järvinen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

rds: Make rds_sock_lock BH rather than IRQ safe.

2012-02-03T17:22:21+00:00

[ Upstream commit efc3dbc37412c027e363736b4f4c74ee5e8ecffc ]

rds_sock_info() triggers locking warnings because we try to perform a
local_bh_enable() (via sock_i_ino()) while hardware interrupts are
disabled (via taking rds_sock_lock).

There is no reason for rds_sock_lock to be a hardware IRQ disabling
lock, none of these access paths run in hardware interrupt context.

Therefore making it a BH disabling lock is safe and sufficient to
fix this bug.

Reported-by: Kumar Sanghvi 
Reported-by: Josh Boyer 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: reintroduce missing rcu_assign_pointer() calls

2012-02-03T17:22:20+00:00

[ Upstream commit cf778b00e96df6d64f8e21b8395d1f8a859ecdc7 ]

commit a9b3cd7f32 (rcu: convert uses of rcu_assign_pointer(x, NULL) to
RCU_INIT_POINTER) did a lot of incorrect changes, since it did a
complete conversion of rcu_assign_pointer(x, y) to RCU_INIT_POINTER(x,
y).

We miss needed barriers, even on x86, when y is not NULL.

Signed-off-by: Eric Dumazet 
CC: Stephen Hemminger 
CC: Paul E. McKenney 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

l2tp: l2tp_ip - fix possible oops on packet receive

2012-02-03T17:22:19+00:00

[ Upstream commit 68315801dbf3ab2001679fd2074c9dc5dcf87dfa ]

When a packet is received on an L2TP IP socket (L2TPv3 IP link
encapsulation), the l2tpip socket's backlog_rcv function calls
xfrm4_policy_check(). This is not necessary, since it was called
before the skb was added to the backlog. With CONFIG_NET_NS enabled,
xfrm4_policy_check() will oops if skb->dev is null, so this trivial
patch removes the call.

This bug has always been present, but only when CONFIG_NET_NS is
enabled does it cause problems. Most users are probably using UDP
encapsulation for L2TP, hence the problem has only recently
surfaced.

EIP: 0060:[] EFLAGS: 00210246 CPU: 0
EIP is at l2tp_ip_recvmsg+0xd4/0x2a7
EAX: 00000001 EBX: d77b5180 ECX: 00000000 EDX: 00200246
ESI: 00000000 EDI: d63cbd30 EBP: d63cbd18 ESP: d63cbcf4
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Call Trace:
 [] sock_common_recvmsg+0x31/0x46
 [] __sock_recvmsg_nosec+0x45/0x4d
 [] __sock_recvmsg+0x31/0x3b
 [] sock_recvmsg+0x96/0xab
 [] ? might_fault+0x47/0x81
 [] ? might_fault+0x47/0x81
 [] ? _copy_from_user+0x31/0x115
 [] ? copy_from_user+0x8/0xa
 [] ? verify_iovec+0x3e/0x78
 [] __sys_recvmsg+0x10a/0x1aa
 [] ? sock_recvmsg+0x0/0xab
 [] ? __lock_acquire+0xbdf/0xbee
 [] ? do_page_fault+0x193/0x375
 [] ? fcheck_files+0x9b/0xca
 [] ? fget_light+0x2a/0x9c
 [] sys_recvmsg+0x2b/0x43
 [] sys_socketcall+0x16d/0x1a5
 [] ? trace_hardirqs_on_thunk+0xc/0x10
 [] sysenter_do_call+0x12/0x38
Code: c6 05 8c ea a8 c1 01 e8 0c d4 d9 ff 85 f6 74 07 3e ff 86 80 00 00 00 b9 17 b6 2b c1 ba 01 00 00 00 b8 78 ed 48 c1 e8 23 f6 d9 ff  76 0c 68 28 e3 30 c1 68 2d 44 41 c1 e8 89 57 01 00 83 c4 0c

Signed-off-by: James Chapman 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

af_unix: fix EPOLLET regression for stream sockets

2012-02-03T17:22:18+00:00

[ Upstream commit 6f01fd6e6f6809061b56e78f1e8d143099716d70 ]

Commit 0884d7aa24 (AF_UNIX: Fix poll blocking problem when reading from
a stream socket) added a regression for epoll() in Edge Triggered mode
(EPOLLET)

Appropriate fix is to use skb_peek()/skb_unlink() instead of
skb_dequeue(), and only call skb_unlink() when skb is fully consumed.

This remove the need to requeue a partial skb into sk_receive_queue head
and the extra sk->sk_data_ready() calls that added the regression.

This is safe because once skb is given to sk_receive_queue, it is not
modified by a writer, and readers are serialized by u->readlock mutex.

This also reduce number of spinlock acquisition for small reads or
MSG_PEEK users so should improve overall performance.

Reported-by: Nick Mathewson 
Signed-off-by: Eric Dumazet 
Cc: Alexey Moiseytsev 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net caif: Register properly as a pernet subsystem.

2012-02-03T17:22:18+00:00

[ Upstream commit 8a8ee9aff6c3077dd9c2c7a77478e8ed362b96c6 ]

caif is a subsystem and as such it needs to register with
register_pernet_subsys instead of register_pernet_device.

Among other problems using register_pernet_device was resulting in
net_generic being called before the caif_net structure was allocated.
Which has been causing net_generic to fail with either BUG_ON's or by
return NULL pointers.

A more ugly problem that could be caused is packets in flight why the
subsystem is shutting down.

To remove confusion also remove the cruft cause by inappropriately
trying to fix this bug.

With the aid of the previous patch I have tested this patch and
confirmed that using register_pernet_subsys makes the failure go away as
it should.

Signed-off-by: Eric W. Biederman 
Acked-by: Sjur Brændeland 
Tested-by: Sasha Levin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netns: fix net_alloc_generic()

2012-02-03T17:22:17+00:00

[ Upstream commit 073862ba5d249c20bd5c49fc6d904ff0e1f6a672 ]

When a new net namespace is created, we should attach to it a "struct
net_generic" with enough slots (even empty), or we can hit the following
BUG_ON() :

[  200.752016] kernel BUG at include/net/netns/generic.h:40!
...
[  200.752016]  [] ? get_cfcnfg+0x3a/0x180
[  200.752016]  [] ? lockdep_rtnl_is_held+0x10/0x20
[  200.752016]  [] caif_device_notify+0x2e/0x530
[  200.752016]  [] notifier_call_chain+0x67/0x110
[  200.752016]  [] raw_notifier_call_chain+0x11/0x20
[  200.752016]  [] call_netdevice_notifiers+0x32/0x60
[  200.752016]  [] register_netdevice+0x196/0x300
[  200.752016]  [] register_netdev+0x19/0x30
[  200.752016]  [] loopback_net_init+0x4a/0xa0
[  200.752016]  [] ops_init+0x42/0x180
[  200.752016]  [] setup_net+0x6b/0x100
[  200.752016]  [] copy_net_ns+0x86/0x110
[  200.752016]  [] create_new_namespaces+0xd9/0x190

net_alloc_generic() should take into account the maximum index into the
ptr array, as a subsystem might use net_generic() anytime.

This also reduces number of reallocations in net_assign_generic()

Reported-by: Sasha Levin 
Tested-by: Sasha Levin 
Signed-off-by: Eric Dumazet 
Cc: Sjur Brændeland 
Cc: Eric W. Biederman 
Cc: Pavel Emelyanov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix work removal on deauth request

2012-02-03T17:21:31+00:00

commit bc4934bc61d0a11fd62c5187ff83645628f8be8b upstream.

When deauth is requested while an auth or assoc
work item is in progress, we currently delete it
without regard for any state it might need to
clean up. Fix it by cleaning up for those items.

In the case Pontus found, the problem manifested
itself as such:

authenticate with 00:23:69:aa:dd:7b (try 1)
authenticated
failed to insert Dummy STA entry for the AP (error -17)
deauthenticating from 00:23:69:aa:dd:7b by local choice (reason=2)

It could also happen differently if the driver
uses the tx_sync callback.

We can't just call the ->done() method of the work
items because that will lock up due to the locking
in cfg80211. This fix isn't very clean, but that
seems acceptable since I have patches pending to
remove this code completely.

Reported-by: Pontus Fuchs 
Tested-by: Pontus Fuchs 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

mac80211: revert on-channel work optimisations

2012-01-26T00:13:37+00:00

commit e76aadc572288a158ae18ae1c10fe395c7bca066 upstream.

Backport note:
This patch it's a full revert of commit b23b025f "mac80211: Optimize
scans on current operating channel.". On upstrem revert e76aadc5 we
keep some bits from that commit, which are needed for upstream version
of mac80211.

The on-channel work optimisations have caused a
number of issues, and the code is unfortunately
very complex and almost impossible to follow.
Instead of attempting to put in more workarounds
let's just remove those optimisations, we can
work on them again later, after we change the
whole auth/assoc design.

This should fix rate_control_send_low() warnings,
see RH bug 731365.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: Greg Kroah-Hartman