netdev - Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround (fwd)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0810021142370.5549@apollo.tec.linutronix.de>
Date:	Thu, 2 Oct 2008 12:42:44 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Dâniel Fraga <fragabr@...il.com>
cc:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround
 (fwd)

On Wed, 1 Oct 2008, Dâniel Fraga wrote:
> On Wed, 1 Oct 2008 22:05:09 +0200 (CEST)
> Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> > One possibility to get deeper insight into this problem is to use the
> > function tracer and stop it once we notice the wreckage. 
> > listenoverflow should be a good point to stop it.
> 
> 	Ok, I'm already running function tracer.
> 
> 	I did the following:
> 
> echo ftrace > /debug/tracing/current_tracer
> echo print-parent > /debug/tracing/iter_ctrl
> 
> 	Is it enough to get what you suggest?

Please add:

  echo sym-offset > /debug/tracing/iter_ctrl
  echo sym-addr > /debug/tracing/iter_ctrl
  echo sym-verbose > /debug/tracing/iter_ctrl

> 	If so, I'll leave it enabled:
> 
> echo 1 > /debug/tracing/tracing_enabled
> 
> 	and stop and get the data just when the problem happens... then
> I should know what I should grep, what's relevant.

I'm not sure, whether manual stop will be sufficient as the relevant
traces might have been gone by that time. 

Find below a patch which disables the tracer when the listen overflow
is detected. It could occassionally be hit in a legimate case as well,
but we did not come up with any better idea.

If it triggers, please cat /debug/tracing/trace to a file. Can you
bzip2 and upload it to some place. The trace does not contain any
sensible private information.

Thanks,

	tglx
---
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index f6e3af3..a1cecb0 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -68,6 +68,12 @@ static void ftrace_list_func(unsigned long ip, unsigned long parent_ip)
 	};
 }
 
+void stop_event_tracer_now(void)
+{
+	tracer_enabled = 0;
+	printk(KERN_INFO "Tracer stopped\n");
+}
+
 /**
  * clear_ftrace_function - reset the ftrace function
  *
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index f976fc5..527dd45 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -485,6 +485,8 @@ struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req,
 	return newsk;
 }
 
+extern void stop_event_tracer_now(void);
+
 /*
  *	Process an incoming packet for SYN_RECV sockets represented
  *	as a request_sock.
@@ -687,6 +689,7 @@ struct sock *tcp_check_req(struct sock *sk,struct sk_buff *skb,
 	return child;
 
 listen_overflow:
+	stop_event_tracer_now();
 	if (!sysctl_tcp_abort_on_overflow) {
 		inet_rsk(req)->acked = 1;
 		return NULL;