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/