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

xfrm: take net hdr len into account for esp payload size calculation

2012-06-09T15:36:15+00:00

[ Upstream commit 91657eafb64b4cb53ec3a2fbc4afc3497f735788 ]

Corrects the function that determines the esp payload size. The calculations
done in esp{4,6}_get_mtu() lead to overlength frames in transport mode for
certain mtu values and suboptimal frames for others.

According to what is done, mainly in esp{,6}_output() and tcp_mtu_to_mss(),
net_header_len must be taken into account before doing the alignment
calculation.

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

l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case

2012-06-09T15:36:15+00:00

[ Upstream commit c51ce49735c183ef2592db70f918ee698716276b ]

An application may call connect() to disconnect a socket using an
address with family AF_UNSPEC. The L2TP IP sockets were not handling
this case when the socket is not bound and an attempt to connect()
using AF_UNSPEC in such cases would result in an oops. This patch
addresses the problem by protecting the sk_prot->disconnect() call
against trying to unhash the socket before it is bound.

The patch also adds more checks that the sockaddr supplied to bind()
and connect() calls is valid.

 RIP: 0010:[]  [] inet_unhash+0x50/0xd0
 RSP: 0018:ffff88001989be28  EFLAGS: 00010293
 Stack:
  ffff8800407a8000 0000000000000000 ffff88001989be78 ffffffff82e3a249
  ffffffff82e3a050 ffff88001989bec8 ffff88001989be88 ffff8800407a8000
  0000000000000010 ffff88001989bec8 ffff88001989bea8 ffffffff82e42639
 Call Trace:
 [] udp_disconnect+0x1f9/0x290
 [] inet_dgram_connect+0x29/0x80
 [] sys_connect+0x9c/0x100

Reported-by: Sasha Levin 
Signed-off-by: James Chapman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: fix incorrect ipsec fragment

2012-06-09T15:36:15+00:00

[ 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

ipv4: fix the rcu race between free_fib_info and ip_route_output_slow

2012-06-09T15:36:14+00:00

[ Upstream commit e49cc0da7283088c5e03d475ffe2fdcb24a6d5b1 ]

We hit a kernel OOPS.

<3>[23898.789643] BUG: sleeping function called from invalid context at
/data/buildbot/workdir/ics/hardware/intel/linux-2.6/arch/x86/mm/fault.c:1103
<3>[23898.862215] in_atomic(): 0, irqs_disabled(): 0, pid: 10526, name:
Thread-6683
<4>[23898.967805] HSU serial 0000:00:05.1: 0000:00:05.2:HSU serial prevented me
to suspend...
<4>[23899.258526] Pid: 10526, comm: Thread-6683 Tainted: G        W
3.0.8-137685-ge7742f9 #1
<4>[23899.357404] HSU serial 0000:00:05.1: 0000:00:05.2:HSU serial prevented me
to suspend...
<4>[23899.904225] Call Trace:
<4>[23899.989209]  [] ? pgtable_bad+0x130/0x130
<4>[23900.000416]  [] __might_sleep+0x10a/0x110
<4>[23900.007357]  [] do_page_fault+0xd1/0x3c0
<4>[23900.013764]  [] ? restore_all+0xf/0xf
<4>[23900.024024]  [] ? napi_complete+0x8b/0x690
<4>[23900.029297]  [] ? pgtable_bad+0x130/0x130
<4>[23900.123739]  [] ? pgtable_bad+0x130/0x130
<4>[23900.128955]  [] error_code+0x5f/0x64
<4>[23900.133466]  [] ? pgtable_bad+0x130/0x130
<4>[23900.138450]  [] ? __ip_route_output_key+0x698/0x7c0
<4>[23900.144312]  [] ? __ip_route_output_key+0x38d/0x7c0
<4>[23900.150730]  [] ip_route_output_flow+0x1f/0x60
<4>[23900.156261]  [] ip4_datagram_connect+0x188/0x2b0
<4>[23900.161960]  [] ? _raw_spin_unlock_bh+0x1f/0x30
<4>[23900.167834]  [] inet_dgram_connect+0x36/0x80
<4>[23900.173224]  [] ? _copy_from_user+0x48/0x140
<4>[23900.178817]  [] sys_connect+0x9a/0xd0
<4>[23900.183538]  [] ? alloc_file+0xdc/0x240
<4>[23900.189111]  [] ? sub_preempt_count+0x3d/0x50

Function free_fib_info resets nexthop_nh->nh_dev to NULL before releasing
fi. Other cpu might be accessing fi. Fixing it by delaying the releasing.

With the patch, we ran MTBF testing on Android mobile for 12 hours
and didn't trigger the issue.

Thank Eric for very detailed review/checking the issue.

Signed-off-by: Yanmin Zhang 
Signed-off-by: Kun Jiang 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sunrpc: fix loss of task->tk_status after rpc_delay call in xprt_alloc_slot

2012-06-09T15:36:09+00:00

commit 1afeaf5c29aa07db25760d2fbed5c08a3aec3498 upstream.

xprt_alloc_slot will call rpc_delay() to make the task wait a bit before
retrying when it gets back an -ENOMEM error from xprt_dynamic_alloc_slot.
The problem is that rpc_delay will clear the task->tk_status, causing
call_reserveresult to abort the task.

The solution is simply to let call_reserveresult handle the ENOMEM error
directly.

Reported-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix ADDBA declined after suspend with wowlan

2012-06-09T15:36:08+00:00

commit 7b21aea04d084916ac4e0e8852dcc9cd60ec0d1d upstream.

WLAN_STA_BLOCK_BA is set while suspending but doesn't get cleared
when resuming in case of wowlan. This causes further ADDBA requests
received to be rejected. Fix it by clearing it in the wowlan path
as well.

Signed-off-by: Eyal Shapira 
Reviewed-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cfg80211: warn if db.txt is empty with CONFIG_CFG80211_INTERNAL_REGDB

2012-06-01T07:18:14+00:00

commit 80007efeff0568375b08faf93c7aad65602cb97e upstream.

It has happened twice now where elaborate troubleshooting has
undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0]
has been set but yet net/wireless/db.txt was not updated.

Despite the documentation on this it seems system integrators could
use some more help with this, so throw out a kernel warning at boot time
when their database is empty.

This does mean that the error-prone system integrator won't likely
realize the issue until they boot the machine but -- it does not seem
to make sense to enable a build bug breaking random build testing.

[0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB

Cc: Stephen Rothwell 
Cc: Youngsin Lee 
Cc: Raja Mani 
Cc: Senthil Kumar Balasubramanian 
Cc: Vipin Mehta 
Cc: yahuan@qca.qualcomm.com
Cc: jjan@qca.qualcomm.com
Cc: vthiagar@qca.qualcomm.com
Cc: henrykim@qualcomm.com
Cc: jouni@qca.qualcomm.com
Cc: athiruve@qca.qualcomm.com
Cc: cjkim@qualcomm.com
Cc: philipk@qca.qualcomm.com
Cc: sunnykim@qualcomm.com
Cc: sskwak@qualcomm.com
Cc: kkim@qualcomm.com
Cc: mattbyun@qualcomm.com
Cc: ryanlee@qualcomm.com
Cc: simbap@qualcomm.com
Cc: krislee@qualcomm.com
Cc: conner@qualcomm.com
Cc: hojinkim@qualcomm.com
Cc: honglee@qualcomm.com
Cc: johnwkim@qualcomm.com
Cc: jinyong@qca.qualcomm.com
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

pktgen: fix module unload for good

2012-05-18T17:54:33+00:00

commit c57b5468406 (pktgen: fix crash at module unload) did a very poor
job with list primitives.

1) list_splice() arguments were in the wrong order

2) list_splice(list, head) has undefined behavior if head is not
initialized.

3) We should use the list_splice_init() variant to clear pktgen_threads
list.

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

tcp: do_tcp_sendpages() must try to push data out on oom conditions

2012-05-17T22:31:43+00:00

Since recent changes on TCP splicing (starting with commits 2f533844
"tcp: allow splice() to build full TSO packets" and 35f9c09f "tcp:
tcp_sendpages() should call tcp_push() once"), I started seeing
massive stalls when forwarding traffic between two sockets using
splice() when pipe buffers were larger than socket buffers.

Latest changes (net: netdev_alloc_skb() use build_skb()) made the
problem even more apparent.

The reason seems to be that if do_tcp_sendpages() fails on out of memory
condition without being able to send at least one byte, tcp_push() is not
called and the buffers cannot be flushed.

After applying the attached patch, I cannot reproduce the stalls at all
and the data rate it perfectly stable and steady under any condition
which previously caused the problem to be permanent.

The issue seems to have been there since before the kernel migrated to
git, which makes me think that the stalls I occasionally experienced
with tux during stress-tests years ago were probably related to the
same issue.

This issue was first encountered on 3.0.31 and 3.2.17, so please backport
to -stable.

Signed-off-by: Willy Tarreau 
Acked-by: Eric Dumazet 
Cc:

netfilter: ipset: fix hash size checking in kernel

2012-05-16T19:38:49+00:00

The hash size must fit both into u32 (jhash) and the max value of
size_t. The missing checking could lead to kernel crash, bug reported
by Seblu.

Signed-off-by: Jozsef Kadlecsik 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: David S. Miller