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]

Date:	Thu, 2 Oct 2008 23:31:28 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	"Dâniel Fraga" <fragabr@...il.com>
cc:	Thomas Gleixner <tglx@...utronix.de>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround
 (fwd)

On Thu, 2 Oct 2008, Thomas Gleixner wrote:

> On Thu, 2 Oct 2008, Dâniel Fraga wrote:
> 
> > On Thu, 2 Oct 2008 14:08:14 +0200 (CEST)
> > Thomas Gleixner <tglx@...utronix.de> wrote:
> > 
> > > grmbl. tracer_enabled should have been ftrace_enabled of course.
> > 
> > 	Ok Thomas. I got a stall on my desktop.
> > 
> > 	It happens when I try to use sudo and it just stay stalled (I
> > think trying to access /dev/log or something like that).

Ah, I was kind of thinking that you were doing something net related 
using some raw socket thing (such as traceroute) when you earlier 
mentioned sudo (iirc, we never really discussed what you usually do with 
it when you see the stall).

> > 	I got the trace here:
> > 
> > http://www.abusar.org/ftrace/trace.txt.bz2
> > 
> > 	after the stall.
> > 
> > 	Could you please check if there's something wrong?
> > 
> > 	I'd prefer if the stall happened in the server, but it still
> > didn't happen. Anyway, it's the same problem.
> 
> Hmm, not sure. sudo is a different beast. All I can see in the trace
> is that reiserfs is turning itself in circles (which is nothing new),
> but there is nothing which might tell us about a stall. At the point
> where you stopped the trace the relevant info was already replaced by
> new stuff. It's a circular buffer which gets overwritten.

We might have had a change if there would have been a (failed) connection 
attempt in it but there seemed to be none.


-- 
 i.