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

[PATCH] NET: Set truesize in pskb_copy

2006-11-19T03:28:03+00:00

Since pskb_copy tacks on the non-linear bits from the original
skb, it needs to count them in the truesize field of the new skb.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

[PATCH] TCP: Don't use highmem in tcp hash size calculation.

2006-11-19T03:28:03+00:00

This patch removes consideration of high memory when determining TCP
hash table sizes.  Taking into account high memory results in tcp_mem
values that are too large.

Signed-off-by: John Heffner 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

[PATCH] NET: __alloc_pages() failures reported due to fragmentation

2006-11-19T03:28:02+00:00

We have seen a couple of __alloc_pages() failures due to
fragmentation, there is plenty of free memory but no large order pages
available.  I think the problem is in sock_alloc_send_pskb(), the
gfp_mask includes __GFP_REPEAT but its never used/passed to the page
allocator.  Shouldnt the gfp_mask be passed to alloc_skb() ?

Signed-off-by: Larry Woodman 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

[PATCH] IPV6: fix lockup via /proc/net/ip6_flowlabel [CVE-2006-5619]

2006-11-04T01:33:50+00:00

There's a bug in the seqfile handling for /proc/net/ip6_flowlabel, where,
after finding a flowlabel, the code will loop forever not finding any
further flowlabels, first traversing the rest of the hash bucket then just
looping.

This patch fixes the problem by breaking after the hash bucket has been
traversed.

Note that this bug can cause lockups and oopses, and is trivially invoked
by an unpriveleged user.

Signed-off-by: James Morris 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright

[PATCH] tcp: cubic scaling error

2006-11-04T01:33:50+00:00

Doug Leith observed a discrepancy between the version of CUBIC described
in the papers and the version in 2.6.18. A math error related to scaling
causes Cubic to grow too slowly.

Patch is from "Sangtae Ha" . I validated that
it does fix the problems.

See the following to show behavior over 500ms 100 Mbit link.

Sender (2.6.19-rc3) ---  Bridge (2.6.18-rt7) ------- Receiver (2.6.19-rc3)
                    1G      [netem]           100M

	http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-orig.png
	http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-fix.png

Signed-off-by: Stephen Hemminger 
Signed-off-by: Chris Wright

[PATCH] SCTP: Always linearise packet on input

2006-11-04T01:33:48+00:00

I was looking at a RHEL5 bug report involving Xen and SCTP
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212550).
It turns out that SCTP wasn't written to handle skb fragments at
all.  The absence of any calls to skb_may_pull is testament to
that.

It just so happens that Xen creates fragmented packets more often
than other scenarios (header & data split when going from domU to
dom0).  That's what caused this bug to show up.

Until someone has the time sits down and audits the entire net/sctp
directory, here is a conservative and safe solution that simply
linearises all packets on input.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Chris Wright

[PATCH] NET: Fix skb_segment() handling of fully linear SKBs

2006-11-04T01:33:48+00:00

[NET]: Fix segmentation of linear packets

skb_segment fails to segment linear packets correctly because it
tries to write all linear parts of the original skb into each
segment.  This will always panic as each segment only contains
enough space for one MSS.

This was not detected earlier because linear packets should be
rare for GSO.  In fact it still remains to be seen what exactly
created the linear packets that triggered this bug.  Basically
the only time this should happen is if someone enables GSO
emulation on an interface that does not support SG.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Chris Wright

[PATCH] knfsd: Fix race that can disable NFS server.

2006-11-04T01:33:47+00:00

This is a long standing bug that seems to have only recently become
apparent, presumably due to increasing use of NFS over TCP - many
distros seem to be making it the default.

The SK_CONN bit gets set when a listening socket may be ready
for an accept, just as SK_DATA is set when data may be available.

It is entirely possible for svc_tcp_accept to be called with neither
of these set.  It doesn't happen often but there is a small race in
svc_sock_enqueue as SK_CONN and SK_DATA are tested outside the
spin_lock.  They could be cleared immediately after the test and
before the lock is gained.

This normally shouldn't be a problem.  The sockets are non-blocking so
trying to read() or accept() when ther is nothing to do is not a problem.

However: svc_tcp_recvfrom makes the decision "Should I accept() or
should I read()" based on whether SK_CONN is set or not.  This usually
works but is not safe.  The decision should be based on whether it is
a TCP_LISTEN socket or a TCP_CONNECTED socket.

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

[PATCH] Bluetooth: Check if DLC is still attached to the TTY

2006-11-04T01:33:46+00:00

[Bluetooth] Check if DLC is still attached to the TTY

If the DLC device is no longer attached to the TTY device, then it
makes no sense to go through with changing the termios settings.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Chris Wright

[PATCH] Fix sfuzz hanging on 2.6.18

2006-11-04T01:33:43+00:00

Dave Jones wrote:
> sfuzz         D 724EF62A  2828 28717  28691                     (NOTLB)
>        cd69fe98 00000082 0000012d 724ef62a 0001971a 00000010 00000007 df6d22b0
>        dfd81080 725bbc5e 0001971a 000cc634 00000001 df6d23bc c140e260 00000202
>        de1d5ba0 cd69fea0 de1d5ba0 00000000 00000000 de1d5b60 de1d5b8c de1d5ba0
> Call Trace:
>  [] lock_sock+0x75/0xa6
>  [] dn_getname+0x18/0x5f [decnet]
>  [] sys_getsockname+0x5c/0xb0
>  [] sys_socketcall+0xef/0x261
>  [] syscall_call+0x7/0xb
> DWARF2 unwinder stuck at syscall_call+0x7/0xb
>
> I wonder if the plethora of lockdep related changes inadvertantly broke something?

Looks like unbalanced locking.

Acked-by: Steven Whitehouse 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Chris Wright