On Wed, 2012-09-05 at 17:30 +0200, Eric Dumazet wrote:

On Wed, 2012-09-05 at 17:01 +0200, Marc Kleine-Budde wrote:

quoted

On 09/05/2012 04:55 PM, Fengguang Wu wrote:

quoted

quoted

quoted

This in turn means the problem doesn't come from the CAN patches, as
both trees have different CAN patches. I'm adding Eric W. Biederman on
Cc as he contributed some sctp patches between v3.6 and net-next/master.

Anything is possible, but this seems unlikely as I don't think I touched
anything close to that part of the code.

You are both right.  The bad commit turns out to be one of:

1bed966cc3bd4042110129f0fc51aeeb59c5b200 Merge branch 'tcp_fastopen_server'
168a8f58059a22feb9e9a2dcc1b8053dbbbc12ef tcp: TCP Fast Open Server - main code path
8336886f786fdacbc19b719c1f7ea91eb70706d4 tcp: TCP Fast Open Server - support TFO listeners

Thanks,
Fengguang

Thanks for your work Fengguang.

Marc

OK I have a good idea how to fix the bug, I will send a patch ASAP

Could you test the following patch please ?

(Not sure why sctp doesnt memset/bzero its whole socket by the way...)

Thanks

diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 4f70ef0..845372b 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c

@@ -149,11 +149,8 @@ void inet_sock_destruct(struct sock *sk)
 		pr_err("Attempt to release alive inet socket %p\n", sk);
 		return;
 	}
-	if (sk->sk_type == SOCK_STREAM) {
-		struct fastopen_queue *fastopenq =
-			inet_csk(sk)->icsk_accept_queue.fastopenq;
-		kfree(fastopenq);
-	}
+	if (sk->sk_protocol == IPPROTO_TCP)
+		kfree(inet_csk(sk)->icsk_accept_queue.fastopenq);
 
 	WARN_ON(atomic_read(&sk->sk_rmem_alloc));
 	WARN_ON(atomic_read(&sk->sk_wmem_alloc));