linux-stable.git/net, branch linux-2.6.19.y

knfsd: Fix a race in closing NFSd connections.

2007-02-24T00:24:27+00:00

If you lose this race, it can iput a socket inode twice and you
get a BUG in fs/inode.c

When I added the option for user-space to close a socket,
I added some cruft to svc_delete_socket so that I could call
that function when closing a socket per user-space request.

This was the wrong thing to do.  I should have just set SK_CLOSE
and let normal mechanisms do the work.

Not only wrong, but buggy.  The locking is all wrong and it openned
up a race where-by a socket could be closed twice.

So this patch:
  Introduces svc_close_socket which sets SK_CLOSE then either leave
  the close up to a thread, or calls svc_delete_socket if it can
  get SK_BUSY.

  Adds a bias to sk_busy which is removed when SK_DEAD is set,
  This avoid races around shutting down the socket.

  Changes several 'spin_lock' to 'spin_lock_bh' where the _bh 
  was missing.

Bugzilla-url: http://bugzilla.kernel.org/show_bug.cgi?id=7916

Signed-off-by: Neil Brown 
Signed-off-by: Greg Kroah-Hartman

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

2007-02-05T16:31:45+00:00

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:45+00:00

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:45+00:00

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:45+00:00

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:45+00:00

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:45+00:00

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:45+00:00

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:44+00:00

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:44+00:00

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