When th is corrupted all that happens is that we might lose an opportunity
to send a tcp frame and it will be sent at some later time. Very
annoying though, especially when debugging other stuff with
SADISTIC_KMALLOC (since then it's always corrupted :)
Patch is against 2.0.37 but it looks the same in the other 2.0's so..
maybe there's a better fix.
-Bjorn
--- tcp_input.c.old Sun Jul 18 12:01:45 1999
+++ tcp_input.c Sun Jul 18 12:05:19 1999
@@ -2297,6 +2297,7 @@
struct tcphdr *th;
struct sock *sk;
__u32 seq;
+ int was_ack;
#ifdef CONFIG_IP_TRANSPARENT_PROXY
int r;
#endif
@@ -2308,6 +2309,7 @@
* etc).
*/
th = skb->h.th;
+ was_ack = th->ack; /* remember for later when we've freed the skb
*/
sk = skb->sk;
#ifdef CONFIG_RST_COOKIES
if (th->rst && secure_tcp_probe_number(saddr,daddr,ntohs(th->source),ntohs(th->dest),ntohl(th->seq),1)) {
@@ -2789,7 +2791,7 @@
* If we had a partial packet being help up due to
* application of Nagle's rule we are now free to send it.
*/
- if (th->ack
+ if (was_ack
&& sk->packets_out == 0
&& sk->partial != NULL
&& skb_queue_empty(&sk->write_queue)
On Fri, 16 Jul 1999, Bjorn Wesen wrote:
> I stumbled over a most weird thing with the 2.0 kernels (tested on 2.0.33
> and 2.0.37). When enabling SADISTIC_KMALLOC in mm/kmalloc.c, packets are
> delayed (or lost) inside the network stack somewhere. Tested on different
> architectures and computers with different NIC's, and no weirdo config
> options.
>
> For example, telnetting to such a machine and typing chars, you get a one
> packet delay - you see the char you pressed _last_ keystroke. Same thing
> in ftp for example, typing ls gives you the first half of the listing and
> then it halts.
>
> 30 seconds later the stack tries again and then it seems to get through.
>
> tcp_sendmsg is called, but the packet never reaches the NIC for
> transmission.
>
> Does anyone know if there is any official reason why sadistic_kmalloc
> would break stuff, if this is not a real bug ?
>
> -Bjorn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/