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

ipv4: udp: fix short packet and bad checksum logging

2010-05-26T21:29:13+00:00

commit ccc2d97cb7c798e785c9f198de243e2b59f7073b upstream.

commit 2783ef23 moved the initialisation of saddr and daddr after
pskb_may_pull() to avoid a potential data corruption.  Unfortunately
also placing it after the short packet and bad checksum error paths,
where these variables are used for logging.  The result is bogus
output like

[92238.389505] UDP: short packet: From 2.0.0.0:65535 23715/178 to 0.0.0.0:65535

Moving the saddr and daddr initialisation above the error paths, while still
keeping it after the pskb_may_pull() to keep the fix from commit 2783ef23.

Signed-off-by: Bjørn Mork 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

dccp_probe: Fix module load dependencies between dccp and dccp_probe

2010-05-12T21:57:11+00:00

commit 38ff3e6bb987ec583268da8eb22628293095d43b upstream.

This was just recently reported to me.  When built as modules, the
dccp_probe module has a silent dependency on the dccp module.  This
stems from the fact that the module_init routine of dccp_probe
registers a jprobe on the dccp_sendmsg symbol.  Since the symbol is
only referenced as a text string (the .symbol_name field in the jprobe
struct) rather than the address of the symbol itself, depmod never
picks this dependency up, and so if you load the dccp_probe module
without the dccp module loaded, the register_jprobe call fails with an
-EINVAL, and the whole module load fails.

The fix is pretty easy, we can just wrap the register_jprobe call in a
try_then_request_module call, which forces the dependency to get
satisfied prior to the probe registration.

Signed-off-by: Neil Horman 
Acked-by: Arnaldo Carvalho de Melo 
Signed-off-by: David S. Miller 
Cc: maximilian attems 
Signed-off-by: Greg Kroah-Hartman

mac80211: remove bogus TX agg state assignment

2010-05-12T21:57:00+00:00

commit b4bb5c3fd9333024044362df67e23e96158489ed upstream.

When the addba timer expires but has no work to do,
it should not affect the state machine. If it does,
TX will not see the successfully established and we
can also crash trying to re-establish the session.

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

mac80211: fix deferred hardware scan requests

2010-04-26T14:41:36+00:00

commit c0ce77b8323c1a0d4eeef97caf16c0ea971222a9 upstream.

Reinette found the reason for the warnings that
happened occasionally when a hw-offloaded scan
finished; her description of the problem:

  mac80211 will defer the handling of scan requests if it is
  busy with management work at the time. The scan requests
  are deferred and run after the work has completed. When
  this occurs there are currently two problems.

  * The scan request for hardware scan is not fully populated
    with the band and channels to scan not initialized.

  * When the scan is queued the state is not correctly updated
    to reflect that a scan is in progress. The problem here is
    that when the driver completes the scan and calls
    ieee80211_scan_completed() a warning will be triggered
    since mac80211 was not aware that a scan was in progress.

The reason is that the queued scan work will start
the hw scan right away when the hw_scan_req struct
has already been allocated. However, in the first
pass it will not have been filled, which happens
at the same time as setting the bits. To fix this,
simply move the allocation after the pending work
test as well, so that the first iteration of the
scan work will call __ieee80211_start_scan() even
in the hardware scan case.

Bug-identified-by: Reinette Chatre 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Cc: Chase Douglas 
Signed-off-by: Greg Kroah-Hartman

nfsd: ensure sockets are closed on error

2010-04-26T14:41:35+00:00

commit 301e99ce4a2f42a317129230fd42e6cd874c64b0 upstream.

One the changes in commit d7979ae4a "svc: Move close processing to a
single place" is:

  err_delete:
-       svc_delete_socket(svsk);
+       set_bit(SK_CLOSE, &svsk->sk_flags);
        return -EAGAIN;

This is insufficient. The recvfrom methods must always call
svc_xprt_received on completion so that the socket gets re-queued if
there is any more work to do.  This particular path did not make that
call because it actually destroyed the svsk, making requeue pointless.
When the svc_delete_socket was change to just set a bit, we should have
added a call to svc_xprt_received,

This is the problem that b0401d7253 attempted to fix, incorrectly.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

Revert "sunrpc: move the close processing after do recvfrom method"

2010-04-26T14:41:35+00:00

commit 1b644b6e6f6160ae35ce4b52c2ca89ed3e356e18 upstream.

This reverts commit b0401d725334a94d57335790b8ac2404144748ee, which
moved svc_delete_xprt() outside of XPT_BUSY, and allowed it to be called
after svc_xpt_recived(), removing its last reference and destroying it
after it had already been queued for future processing.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

Revert "sunrpc: fix peername failed on closed listener"

2010-04-26T14:41:35+00:00

commit f5822754ea006563e1bf0a1f43faaad49c0d8bb2 upstream.

This reverts commit b292cf9ce70d221c3f04ff62db5ab13d9a249ca8.  The
commit that it attempted to patch up,
b0401d725334a94d57335790b8ac2404144748ee, was fundamentally wrong, and
will also be reverted.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

nfsd4: don't try to map gid's in generic rpc code

2010-04-26T14:41:35+00:00

commit dc83d6e27fa80babe31c80aa8568f125f72edf57 upstream.

For nfsd we provide users the option of mapping uid's to server-side
supplementary group lists.  That makes sense for nfsd, but not
necessarily for other rpc users (such as the callback client).

So move that lookup to svcauth_unix_set_client, which is a
program-specific method.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

tcp: fix ICMP-RTO war

2010-04-26T14:41:34+00:00

commit 598856407d4e20ebb4de01a91a93d89325924d43 upstream.

Make sure, that TCP has a nonzero RTT estimation after three-way
handshake. Currently, a listening TCP has a value of 0 for srtt,
rttvar and rto right after the three-way handshake is completed
with TCP timestamps disabled.
This will lead to corrupt RTO recalculation and retransmission
flood when RTO is recalculated on backoff reversion as introduced
in "Revert RTO on ICMP destination unreachable"
(f1ecd5d9e7366609d640ff4040304ea197fbc618).
This behaviour can be provoked by connecting to a server which
"responds first" (like SMTP) and rejecting every packet after
the handshake with dest-unreachable, which will lead to softirq
load on the server (up to 30% per socket in some tests).

Thanks to Ilpo Jarvinen for providing debug patches and to
Denys Fedoryshchenko for reporting and testing.

Changes since v3: Removed bad characters in patchfile.

Reported-by: Denys Fedoryshchenko 
Signed-off-by: Damian Lukowski 
Signed-off-by: David S. Miller 
Cc: maximilian attems 
Signed-off-by: Greg Kroah-Hartman

mac80211: tear down all agg queues when restart/reconfig hw

2010-04-26T14:41:18+00:00

commit 74e2bd1fa3ae9695af566ad5a7a288898787b909 upstream.

When there is a need to restart/reconfig hw, tear down all the
aggregation queues and let the mac80211 and driver get in-sync to have
the opportunity to re-establish the aggregation queues again.

Need to wait until driver re-establish all the station information before tear
down the aggregation queues, driver(at least iwlwifi driver) will reject the
stop aggregation queue request if station is not ready. But also need to make
sure the aggregation queues are tear down before waking up the queues, so
mac80211 will not sending frames with aggregation bit set.

Signed-off-by: Wey-Yi Guy 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman