linux.git/net, branch v2.6.14

[TCP]: Clear stale pred_flags when snd_wnd changes

2005-10-27T17:11:04+00:00

This bug is responsible for causing the infamous "Treason uncloaked"
messages that's been popping up everywhere since the printk was added.
It has usually been blamed on foreign operating systems.  However,
some of those reports implicate Linux as both systems are running
Linux or the TCP connection is going across the loopback interface.

In fact, there really is a bug in the Linux TCP header prediction code
that's been there since at least 2.1.8.  This bug was tracked down with
help from Dale Blount.

The effect of this bug ranges from harmless "Treason uncloaked"
messages to hung/aborted TCP connections.  The details of the bug
and fix is as follows.

When snd_wnd is updated, we only update pred_flags if
tcp_fast_path_check succeeds.  When it fails (for example,
when our rcvbuf is used up), we will leave pred_flags with
an out-of-date snd_wnd value.

When the out-of-date pred_flags happens to match the next incoming
packet we will again hit the fast path and use the current snd_wnd
which will be wrong.

In the case of the treason messages, it just happens that the snd_wnd
cached in pred_flags is zero while tp->snd_wnd is non-zero.  Therefore
when a zero-window packet comes in we incorrectly conclude that the
window is non-zero.

In fact if the peer continues to send us zero-window pure ACKs we
will continue making the same mistake.  It's only when the peer
transmits a zero-window packet with data attached that we get a
chance to snap out of it.  This is what triggers the treason
message at the next retransmit timeout.

Signed-off-by: Herbert Xu 
Signed-off-by: Arnaldo Carvalho de Melo

[PATCH] svcsock timestamp fix

2005-10-26T17:39:43+00:00

Convert nanoseconds to microseconds correctly.

Spotted by Steve Dickson 

Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] kill massive wireless-related log spam

2005-10-26T17:39:43+00:00

Although this message is having the intended effect of causing wireless
driver maintainers to upgrade their code, I never should have merged this
patch in its present form.  Leading to tons of bug reports and unhappy
users.

Some wireless apps poll for statistics regularly, which leads to a printk()
every single time they ask for stats.  That's a little bit _too_ much of a
reminder that the driver is using an old API.

Change this to printing out the message once, per kernel boot.

Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[TR]: Preserve RIF flag even for 2 byte RIF fields.

2005-10-25T23:31:38+00:00

Signed-off-by: Jochen Friedrich 
Signed-off-by: Arnaldo Carvalho de Melo

[IPV6]: Fix refcnt of struct ip6_flowlabel

2005-10-25T23:17:52+00:00

Signed-off-by: Yan Zheng 
Acked-by: YOSHIFUJI Hideaki 
Signed-off-by: Arnaldo Carvalho de Melo

[NEIGH] Fix timer leak in neigh_changeaddr

2005-10-23T07:18:00+00:00

neigh_changeaddr attempts to delete neighbour timers without setting
nud_state.  This doesn't work because the timer may have already fired
when we acquire the write lock in neigh_changeaddr.  The result is that
the timer may keep firing for quite a while until the entry reaches
NEIGH_FAILED.

It should be setting the nud_state straight away so that if the timer
has already fired it can simply exit once we relinquish the lock.

In fact, this whole function is simply duplicating the logic in
neigh_ifdown which in turn is already doing the right thing when
it comes to deleting timers and setting nud_state.

So all we have to do is take that code out and put it into a common
function and make both neigh_changeaddr and neigh_ifdown call it.

Signed-off-by: Herbert Xu

[NEIGH] Fix add_timer race in neigh_add_timer

2005-10-23T06:37:48+00:00

neigh_add_timer cannot use add_timer unconditionally.  The reason is that
by the time it has obtained the write lock someone else (e.g., neigh_update)
could have already added a new timer.

So it should only use mod_timer and deal with its return value accordingly.

This bug would have led to rare neighbour cache entry leaks.

Signed-off-by: Herbert Xu

[NEIGH] Print stack trace in neigh_add_timer

2005-10-23T06:11:39+00:00

Stack traces are very helpful in determining the exact nature of a bug.
So let's print a stack trace when the timer is added twice.

Signed-off-by: Herbert Xu

[SK_BUFF]: ipvs_property field must be copied

2005-10-22T19:06:01+00:00

IPVS used flag NFC_IPVS_PROPERTY in nfcache but as now nfcache was removed the
new flag 'ipvs_property' still needs to be copied. This patch should be
included in 2.6.14.

Further comments from Harald Welte:

Sorry, seems like the bug was introduced by me.

Signed-off-by: Julian Anastasov 
Signed-off-by: Harald Welte 
Signed-off-by: Arnaldo Carvalho de Melo

[TCP] Allow len == skb->len in tcp_fragment

2005-10-20T19:13:13+00:00

It is legitimate to call tcp_fragment with len == skb->len since
that is done for FIN packets and the FIN flag counts as one byte.
So we should only check for the len > skb->len case.

Signed-off-by: Herbert Xu 
Signed-off-by: Arnaldo Carvalho de Melo