[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100810083040.GB6801@basil.fritz.box>
Date: Tue, 10 Aug 2010 10:30:40 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Andi Kleen <andi@...stfloor.org>, netdev@...r.kernel.org
Subject: Re: [RFC] [PATCH] Don't destroy TCP sockets twice
On Mon, Aug 09, 2010 at 05:30:02PM -0400, Herbert Xu wrote:
> Andi Kleen <andi@...stfloor.org> wrote:
> >
> > While working on something else I noticed that tcp_v4/6_destroy_sock()
> > can get called twice on a socket. This happens because when a reset or
> > similar happens tcp_done destroys the connection socket state, and
> > then eventually when the socket is released it is destroyed again.
>
> I'm still having problems understanding why you're getting a call
> to send a FIN after tcp_done. This shouldn't happen at all because
> tcp_done moves the socket to the TCP_CLOSE state, where FINs should
> not be sent.
>
> Can you clarify on how we can reproduce this problem in the
> upstream kernel?
This simple patch demonstrates double destroy. I have patches for showing
the more complicated case too, but they're much more ugly.
-Andi
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index a778ee0..bfbb06b 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -459,6 +459,8 @@ struct tcp_sock {
* contains related tcp_cookie_transactions fields.
*/
struct tcp_cookie_values *cookie_values;
+
+ int destroyed;
};
static inline struct tcp_sock *tcp_sk(const struct sock *sk)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 0207662..25bf80a 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1919,6 +1919,9 @@ void tcp_v4_destroy_sock(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
+ BUG_ON(tp->destroyed != 0);
+ tp->destroyed = 1;
+
tcp_clear_xmit_timers(sk);
tcp_cleanup_congestion_control(sk);
--
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists