Messages in this thread Patch in this message | | | Date | Tue, 17 Nov 1998 19:01:34 -0800 | From | "David S. Miller" <> | Subject | Re: 2.1.129pre5 TCP Bug (?) |
| |
Date: Tue, 17 Nov 1998 11:17:50 -0800 (PST) From: Simon Kirby <sim@netnation.com>
On Tue, 17 Nov 1998, Simon Kirby wrote:
> Installed 2.1.129pre5 on a fairly small webserver and let it go for a few > minutes. This came up in the log: > > tcp_fin: Impossible, sk->state=7
I should note that the message is still occurring, about once a minute. Would it be helpful to record a tcpdump and try to line up the message to a packet?
Please try this patch:
--- net/ipv4/tcp_input.c.~1~ Thu Nov 12 00:01:42 1998 +++ net/ipv4/tcp_input.c Tue Nov 17 20:02:55 1998 @@ -1978,8 +1978,27 @@ struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp); int queued = 0; - /* state == CLOSED, hash lookup always fails, so no worries. -DaveM */ switch (sk->state) { + case TCP_CLOSE: + /* When state == CLOSED, hash lookup always fails. + * + * But, there is a back door, the backlog queue. + * If we have a sequence of packets in the backlog + * during __release_sock() which have a sequence such + * that: + * packet X causes entry to TCP_CLOSE state + * ... + * packet X + N has FIN bit set + * + * We report a (luckily) harmless error in this case. + * The issue is that backlog queue processing bypasses + * any hash lookups (we know which socket packets are for). + * The correct behavior here is what 2.0.x did, since + * a TCP_CLOSE socket does not exist. Drop the frame + * and send a RST back to the other end. + */ + return 1; + case TCP_LISTEN: /* These use the socket TOS.. * might want to be the received TOS - 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/
| |