linux/net, branch v2.6.19.4

[PATCH] SUNRPC: Give cloned RPC clients their own rpc_pipefs directory

2007-02-05T16:31:45Z

This patch fixes a regression in 2.6.19 in which the use of multiple krb5 mounts against the same NFS server may result in an Oops on unmount. The Oops is due to the fact that multiple NFS krb5 clients may end up inadvertently sharing the same rpc_pipefs upcall pipe. The first client to 'umount' will unlink that shared pipe, causing an Oops. The solution is to give each client their own upcall pipe. This fix has been in mainline since 2.6.20-rc1. Signed-off-by: Trond Myklebust [chrisw: backport to 2.6.19.2] Signed-off-by: Chris Wright

[PATCH] NETFILTER: xt_connbytes: fix division by zero

2007-02-05T16:31:45Z

When the packet counter of a connection is zero a division by zero occurs in div64_64(). Fix that by using zero as average value, which is correct as long as the packet counter didn't overflow, at which point we have lost anyway. Additionally we're probably going to go back to 64 bit counters in 2.6.21. Based on patch from Jonas Berlin , with suggestions from KOVACS Krisztian . Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright

[PATCH] TCP: skb is unexpectedly freed.

2007-02-05T16:31:45Z

I encountered a kernel panic with my test program, which is a very simple IPv6 client-server program. The server side sets IPV6_RECVPKTINFO on a listening socket, and the client side just sends a message to the server. Then the kernel panic occurs on the server. (If you need the test program, please let me know. I can provide it.) This problem happens because a skb is forcibly freed in tcp_rcv_state_process(). When a socket in listening state(TCP_LISTEN) receives a syn packet, then tcp_v6_conn_request() will be called from tcp_rcv_state_process(). If the tcp_v6_conn_request() successfully returns, the skb would be discarded by __kfree_skb(). However, in case of a listening socket which was already set IPV6_RECVPKTINFO, an address of the skb will be stored in treq->pktopts and a ref count of the skb will be incremented in tcp_v6_conn_request(). But, even if the skb is still in use, the skb will be freed. Then someone still using the freed skb will cause the kernel panic. I suggest to use kfree_skb() instead of __kfree_skb(). Signed-off-by: Masayuki Nakagawa Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] TCP: Fix sorting of SACK blocks.

2007-02-05T16:31:45Z

The sorting of SACK blocks actually munges them rather than sort, causing the TCP stack to ignore some SACK information and breaking the assumption of ordered SACK blocks after sorting. The sort takes the data from a second buffer which isn't moved causing subsequent data moves to occur from the wrong location. The fix is to use a temporary buffer as a normal sort does. Signed-off-By: Baruch Even Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] TCP: rare bad TCP checksum with 2.6.19

2007-02-05T16:31:45Z

The patch "Replace CHECKSUM_HW by CHECKSUM_PARTIAL/CHECKSUM_COMPLETE" changed to unconditional copying of ip_summed field from collapsed skb. This patch reverts this change. The majority of substantial work including heavy testing and diagnosing by: Michael Tokarev Possible reasons pointed by: Herbert Xu and Patrick McHardy. Signed-off-by: Jarek Poplawski Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] AF_PACKET: Check device down state before hard header callbacks.

2007-02-05T16:31:45Z

If the device is down, invoking the device hard header callbacks is not legal, so check it early. Based upon a shaper OOPS report from Frederik Deweerdt. Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] AF_PACKET: Fix BPF handling.

2007-02-05T16:31:45Z

This fixes a bug introduced by: commit fda9ef5d679b07c9d9097aaf6ef7f069d794a8f9 Author: Dmitry Mishin Date: Thu Aug 31 15:28:39 2006 -0700 [NET]: Fix sk->sk_filter field access sk_run_filter() returns either 0 or an unsigned 32-bit length which says how much of the packet to retain. If that 32-bit unsigned integer is larger than the packet, this is fine we just leave the packet unchanged. The above commit caused all filter return values which were negative when interpreted as a signed integer to indicate a packet drop, which is wrong. Based upon a report and initial patch by Raivis Bucis. Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] IPV4: Fix single-entry /proc/net/fib_trie output.

2007-02-05T16:31:44Z

When main table is just a single leaf this gets printed as belonging to the local table in /proc/net/fib_trie. A fix is below. Signed-off-by: Robert Olsson Acked-by: Eric W. Biederman Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] IPV4: Fix the fib trie iterator to work with a single entry routing tables

2007-02-05T16:31:44Z

In a kernel with trie routing enabled I had a simple routing setup with only a single route to the outside world and no default route. "ip route table list main" showed my the route just fine but /proc/net/route was an empty file. What was going on? Thinking it was a bug in something I did and I looked deeper. Eventually I setup a second route and everything looked correct, huh? Finally I realized that the it was just the iterator pair in fib_trie_get_first, fib_trie_get_next just could not handle a routing table with a single entry. So to save myself and others further confusion, here is a simple fix for the fib proc iterator so it works even when there is only a single route in a routing table. Signed-off-by: Eric W. Biederman Signed-off-by: Robert Olsson Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] DECNET: Handle a failure in neigh_parms_alloc (take 2)

2007-02-05T16:31:44Z

While enhancing the neighbour code to handle multiple network namespaces I noticed that decnet is assuming neigh_parms_alloc will allways succeed, which is clearly wrong. So handle the failure. Signed-off-by: Eric W. Biederman Acked-by: Steven Whitehouse Signed-off-by: David S. Miller Signed-off-by: Chris Wright