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

TCP: Fix TCP handling of SACK in bidirectional flows.

2007-08-31T06:01:51+00:00

It's possible that new SACK blocks that should trigger new LOST
markings arrive with new data (which previously made is_dupack
false). In addition, I think this fixes a case where we get
a cumulative ACK with enough SACK blocks to trigger the fast
recovery (is_dupack would be false there too).

I'm not completely pleased with this solution because readability
of the code is somewhat questionable as 'is_dupack' in SACK case
is no longer about dupacks only but would mean something like
'lost_marker_work_todo' too... But because of Eifel stuff done
in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to
the if statement which seems attractive solution. Nevertheless,
I didn't like adding another variable just for that either... :-)

Signed-off-by: Ilpo Järvinen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

TCP: Fix TCP rate-halving on bidirectional flows.

2007-08-31T06:01:51+00:00

Actually, the ratehalving seems to work too well, as cwnd is
reduced on every second ACK even though the packets in flight
remains unchanged. Recoveries in a bidirectional flows suffer
quite badly because of this, both NewReno and SACK are affected.

After this patch, rate halving is performed for ACK only if
packets in flight was supposedly changed too.

Signed-off-by: Ilpo Järvinen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

TCP: Do not autobind ports for TCP sockets

2007-08-31T06:01:51+00:00

[TCP]: Invoke tcp_sendmsg() directly, do not use inet_sendmsg().

As discovered by Evegniy Polyakov, if we try to sendmsg after
a connection reset, we can do incredibly stupid things.

The core issue is that inet_sendmsg() tries to autobind the
socket, but we should never do that for TCP.  Instead we should
just go straight into TCP's sendmsg() code which will do all
of the necessary state and pending socket error checks.

TCP's sendpage already directly vectors to tcp_sendpage(), so this
merely brings sendmsg() in line with that.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

NET: Fix missing rcu unlock in __sock_create()

2007-08-31T06:01:50+00:00

[NET]: Fix unbalanced rcu_read_unlock in __sock_create

The recent RCU work created an unbalanced rcu_read_unlock
in __sock_create.  This patch fixes that.  Reported by
oleg 123.

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

SNAP: Fix SNAP protocol header accesses.

2007-08-31T06:01:50+00:00

The snap_rcv code reads 5 bytes so we should make sure that
we have 5 bytes in the head before proceeding.

Based on diagnosis and fix by Evgeniy Polyakov, reported by
Alan J. Wylie.

Patch also kills the skb->sk assignment before kfree_skb
since it's redundant.

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

IPv6: Invalid semicolon after if statement

2007-08-31T06:01:33+00:00

Author: Ilpo Järvinen 

A similar fix to netfilter from Eric Dumazet inspired me to
look around a bit by using some grep/sed stuff as looking for
this kind of bugs seemed easy to automate. This is one of them
I found where it looks like this semicolon is not valid.

Signed-off-by: Ilpo Järvinen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

IPV6: Fix kernel panic while send SCTP data with IP fragments

2007-08-31T06:01:01+00:00

If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
kernel panic will occur when SCTP DATA is send again.

This is because of a bad dest address when call to skb_copy_bits().

The messages sequence is like this:

Endpoint A                             Endpoint B
                               <-------  SCTP DATA (size=1432)
ICMP6 message ------->
(Packet Too Big pmtu=1280)
                               <-------  Resend SCTP DATA (size=1432)
------------kernel panic---------------

 printing eip:
c05be62a
*pde = 00000000
Oops: 0002 [#1]
SMP
Modules linked in: scomm l2cap bluetooth ipv6 dm_mirror dm_mod video output sbs battery lp floppy sg i2c_piix4 i2c_core pcnet32 mii button ac parport_pc parport ide_cd cdrom serio_raw mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU:    0
EIP:    0060:[]    Not tainted VLI
EFLAGS: 00010282   (2.6.23-rc2 #1)
EIP is at skb_copy_bits+0x4f/0x1ef
eax: 000004d0   ebx: ce12a980   ecx: 00000134   edx: cfd5a880
esi: c8246858   edi: 00000000   ebp: c0759b14   esp: c0759adc
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
Process swapper (pid: 0, ti=c0759000 task=c06d0340 task.ti=c0713000)
Stack: c0759b88 c0405867 ce12a980 c8bff838 c789c084 00000000 00000028 cfd5a880
       d09f1890 000005dc 0000007b ce12a980 cfd5a880 c8bff838 c0759b88 d09bc521
       000004d0 fffff96c 00000200 00000100 c0759b50 cfd5a880 00000246 c0759bd4
Call Trace:
 [] show_trace_log_lvl+0x1a/0x2f
 [] show_stack_log_lvl+0x9b/0xa3
 [] show_registers+0x1b8/0x289
 [] die+0x113/0x246
 [] do_page_fault+0x4ad/0x57e
 [] error_code+0x72/0x78
 [] ip6_output+0x8e5/0xab2 [ipv6]
 [] ip6_xmit+0x2ea/0x3a3 [ipv6]
 [] sctp_v6_xmit+0x248/0x253 [sctp]
 [] sctp_packet_transmit+0x53f/0x5ae [sctp]
 [] sctp_outq_flush+0x555/0x587 [sctp]
 [] sctp_retransmit+0xf8/0x10f [sctp]
 [] sctp_icmp_frag_needed+0x57/0x5b [sctp]
 [] sctp_v6_err+0xcd/0x148 [sctp]
 [] icmpv6_notify+0xe6/0x167 [ipv6]
 [] icmpv6_rcv+0x7d7/0x849 [ipv6]
 [] ip6_input+0x1dc/0x310 [ipv6]
 [] ipv6_rcv+0x294/0x2df [ipv6]
 [] netif_receive_skb+0x2d2/0x335
 [] process_backlog+0x7f/0xd0
 [] net_rx_action+0x96/0x17e
 [] __do_softirq+0x64/0xcd
 [] do_softirq+0x5c/0xac
 =======================
Code: 00 00 29 ca 89 d0 2b 45 e0 89 55 ec 85 c0 7e 35 39 45 08 8b 55 e4 0f 4e 45 08 8b 75 e0 8b 7d dc 89 c1 c1 e9 02 03 b2 a0 00 00 00  a5 89 c1 83 e1 03 74 02 f3 a4 29 45 08 0f 84 7b 01 00 00 01
EIP: [] skb_copy_bits+0x4f/0x1ef SS:ESP 0068:c0759adc
Kernel panic - not syncing: Fatal exception in interrupt

Arnaldo says:
====================
Thanks! I'm to blame for this one, problem was introduced in:

b0e380b1d8a8e0aca215df97702f99815f05c094

                /*
                 *      Copy a block of the IP datagram.
                 */
-               if (skb_copy_bits(skb, ptr, frag->h.raw, len))
+               if (skb_copy_bits(skb, ptr, skb_transport_header(skb),
len))
                        BUG();
                left -= len;
====================

Signed-off-by: Wei Yongjun 
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

DCCP: Fix DCCP GFP_KERNEL allocation in atomic context

2007-08-31T06:01:01+00:00

This fixes the following bug reported in syslog:

[ 4039.051658] BUG: sleeping function called from invalid context at /usr/src/davem-2.6/mm/slab.c:3032
[ 4039.051668] in_atomic():1, irqs_disabled():0
[ 4039.051670] INFO: lockdep is turned off.
[ 4039.051674]  [] show_trace_log_lvl+0x1a/0x30
[ 4039.051687]  [] show_trace+0x12/0x14
[ 4039.051691]  [] dump_stack+0x16/0x18
[ 4039.051695]  [] __might_sleep+0xaf/0xbe
[ 4039.051700]  [] __kmalloc+0xb1/0xd0
[ 4039.051706]  [] ccid2_hc_tx_alloc_seq+0x35/0xc3 [dccp_ccid2]
[ 4039.051717]  [] ccid2_hc_tx_packet_sent+0x27f/0x2d9 [dccp_ccid2]
[ 4039.051723]  [] dccp_write_xmit+0x1eb/0x338 [dccp]
[ 4039.051741]  [] dccp_sendmsg+0x113/0x18f [dccp]
[ 4039.051750]  [] inet_sendmsg+0x2e/0x4c
[ 4039.051758]  [] sock_aio_write+0xd5/0x107
[ 4039.051766]  [] do_sync_write+0xcd/0x11c
[ 4039.051772]  [] vfs_write+0x118/0x11f
[ 4039.051840]  [] sys_write+0x3d/0x64
[ 4039.051845]  [] syscall_call+0x7/0xb
[ 4039.051848]  =======================

The problem was that GFP_KERNEL was used; fixed by using gfp_any().

Signed-off-by: Gerrit Renker 
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

NET: Share correct feature code between bridging and bonding

2007-08-31T06:01:00+00:00

[NET]: Share correct feature code between bridging and bonding

http://bugzilla.kernel.org/show_bug.cgi?id=8797 shows that the
bonding driver may produce bogus combinations of the checksum
flags and SG/TSO.

For example, if you bond devices with NETIF_F_HW_CSUM and
NETIF_F_IP_CSUM you'll end up with a bonding device that
has neither flag set.  If both have TSO then this produces
an illegal combination.

The bridge device on the other hand has the correct code to
deal with this.

In fact, the same code can be used for both.  So this patch
moves that logic into net/core/dev.c and uses it for both
bonding and bridging.

In the process I've made small adjustments such as only
setting GSO_ROBUST if at least one constituent device
supports it.

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

softmac: Fix deadlock of wx_set_essid with assoc work

2007-08-15T16:25:09+00:00

The essid wireless extension does deadlock against the assoc mutex,
as we don't unlock the assoc mutex when flushing the workqueue, which
also holds the lock.

Signed-off-by: Michael Buesch 
Signed-off-by: Greg Kroah-Hartman