linux-toradex.git/net, branch v2.6.34.8

net: blackhole route should always be recalculated

2011-01-06T23:08:15+00:00

commit ae2688d59b5f861dc70a091d003773975d2ae7fb upstream.

Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error
triggered by IKE for example), hence this kind of route is always
temporary and so we should check if a better route exists for next
packets.
Bug has been introduced by commit d11a4dc18bf41719c9f0d7ed494d295dd2973b92.

Signed-off-by: Jianzhao Wang 
Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

rose: Fix signedness issues wrt. digi count.

2011-01-06T23:08:14+00:00

commit 9828e6e6e3f19efcb476c567b9999891d051f52f upstream.

Just use explicit casts, since we really can't change the
types of structures exported to userspace which have been
around for 15 years or so.

Reported-by: Dan Rosenberg 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

tcp: Fix race in tcp_poll

2011-01-06T23:08:14+00:00

commit a4d258036ed9b2a1811c3670c6099203a0f284a0 upstream.

If a RST comes in immediately after checking sk->sk_err, tcp_poll will
return POLLIN but not POLLOUT.  Fix this by checking sk->sk_err at the end
of tcp_poll.  Additionally, ensure the correct order of operations on SMP
machines with memory barriers.

Signed-off-by: Tom Marshall 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

net: clear heap allocations for privileged ethtool actions

2011-01-06T23:08:14+00:00

commit b00916b189d13a615ff05c9242201135992fcda3 upstream.

Several other ethtool functions leave heap uncleared (potentially) by
drivers. Some interfaces appear safe (eeprom, etc), in that the sizes
are well controlled. In some situations (e.g. unchecked error conditions),
the heap will remain unchanged in areas before copying back to userspace.
Note that these are less of an issue since these all require CAP_NET_ADMIN.

[PG: 34 doesn't have ethtool_get_rxnfc(), drop that chunk]

Signed-off-by: Kees Cook 
Acked-by: Ben Hutchings 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

ip: fix truesize mismatch in ip fragmentation

2011-01-06T23:08:14+00:00

commit 3d13008e7345fa7a79d8f6438150dc15d6ba6e9d upstream.

Special care should be taken when slow path is hit in ip_fragment() :

When walking through frags, we transfert truesize ownership from skb to
frags. Then if we hit a slow_path condition, we must undo this or risk
uncharging frags->truesize twice, and in the end, having negative socket
sk_wmem_alloc counter, or even freeing socket sooner than expected.

Many thanks to Nick Bowler, who provided a very clean bug report and
test program.

Thanks to Jarek for reviewing my first patch and providing a V2

While Nick bisection pointed to commit 2b85a34e911 (net: No more
expensive sock_hold()/sock_put() on each tx), underlying bug is older
(2.6.12-rc5)

A side effect is to extend work done in commit b2722b1c3a893e
(ip_fragment: also adjust skb->truesize for packets not owned by a
socket) to ipv6 as well.

Reported-and-bisected-by: Nick Bowler 
Tested-by: Nick Bowler 
Signed-off-by: Eric Dumazet 
CC: Jarek Poplawski 
CC: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

net: Fix IPv6 PMTU disc. w/ asymmetric routes

2011-01-06T23:08:13+00:00

commit ae878ae280bea286ff2b1e1cb6e609dd8cb4501d upstream.

Signed-off-by: Maciej Żenczykowski 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

Phonet: Correct header retrieval after pskb_may_pull

2011-01-06T23:08:13+00:00

commit a91e7d471e2e384035b9746ea707ccdcd353f5dd upstream.

Retrieve the header after doing pskb_may_pull since, pskb_may_pull
could change the buffer structure.

This is based on the comment given by Eric Dumazet on Phonet
Pipe controller patch for a similar problem.

Signed-off-by: Kumar Sanghvi 
Acked-by: Linus Walleij 
Acked-by: Eric Dumazet 
Acked-by: Rémi Denis-Courmont 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

net: Fix the condition passed to sk_wait_event()

2011-01-06T23:08:13+00:00

commit 482964e56e1320cb7952faa1932d8ecf59c4bf75 upstream.

This patch fixes the condition (3rd arg) passed to sk_wait_event() in
sk_stream_wait_memory(). The incorrect check in sk_stream_wait_memory()
causes the following soft lockup in tcp_sendmsg() when the global tcp
memory pool has exhausted.

>>> snip <<<

localhost kernel: BUG: soft lockup - CPU#3 stuck for 11s! [sshd:6429]
localhost kernel: CPU 3:
localhost kernel: RIP: 0010:[sk_stream_wait_memory+0xcd/0x200]  [sk_stream_wait_memory+0xcd/0x200] sk_stream_wait_memory+0xcd/0x200
localhost kernel:
localhost kernel: Call Trace:
localhost kernel:  [sk_stream_wait_memory+0x1b1/0x200] sk_stream_wait_memory+0x1b1/0x200
localhost kernel:  [] autoremove_wake_function+0x0/0x40
localhost kernel:  [ipv6:tcp_sendmsg+0x6e6/0xe90] tcp_sendmsg+0x6e6/0xce0
localhost kernel:  [sock_aio_write+0x126/0x140] sock_aio_write+0x126/0x140
localhost kernel:  [xfs:do_sync_write+0xf1/0x130] do_sync_write+0xf1/0x130
localhost kernel:  [] autoremove_wake_function+0x0/0x40
localhost kernel:  [hrtimer_start+0xe3/0x170] hrtimer_start+0xe3/0x170
localhost kernel:  [vfs_write+0x185/0x190] vfs_write+0x185/0x190
localhost kernel:  [sys_write+0x50/0x90] sys_write+0x50/0x90
localhost kernel:  [system_call+0x7e/0x83] system_call+0x7e/0x83

>>> snip <<<

What is happening is, that the sk_wait_event() condition passed from
sk_stream_wait_memory() evaluates to true for the case of tcp global memory
exhaustion. This is because both sk_stream_memory_free() and vm_wait are true
which causes sk_wait_event() to *not* call schedule_timeout().
Hence sk_stream_wait_memory() returns immediately to the caller w/o sleeping.
This causes the caller to again try allocation, which again fails and again
calls sk_stream_wait_memory(), and so on.

[ Bug introduced by commit c1cbe4b7ad0bc4b1d98ea708a3fecb7362aa4088
  ("[NET]: Avoid atomic xchg() for non-error case") -DaveM ]

Signed-off-by: Nagendra Singh Tomar 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

tcp: Fix >4GB writes on 64-bit.

2011-01-06T23:08:13+00:00

commit 01db403cf99f739f86903314a489fb420e0e254f upstream.

Fixes kernel bugzilla #16603

tcp_sendmsg() truncates iov_len to an 'int' which a 4GB write to write
zero bytes, for example.

There is also the problem higher up of how verify_iovec() works.  It
wants to prevent the total length from looking like an error return
value.

However it does this using 'int', but syscalls return 'long' (and
thus signed 64-bit on 64-bit machines).  So it could trigger
false-positives on 64-bit as written.  So fix it to use 'long'.

Reported-by: Olaf Bonorden 
Reported-by: Daniel Büse 
Reported-by: Andrew Morton 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

xfrm4: strip ECN bits from tos field

2011-01-06T23:08:13+00:00

commit 94e2238969e89f5112297ad2a00103089dde7e8f upstream.

otherwise ECT(1) bit will get interpreted as RTO_ONLINK
and routing will fail with XfrmOutBundleGenError.

Signed-off-by: Ulrich Weber 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker