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:	Tue, 17 Aug 2010 19:07:11 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Dave Chinner <david@...morbit.com>
Cc:	Lai Jiangshan <laijs@...fujitsu.com>, linux-kernel@...r.kernel.org
Subject: Re: [tracing, hang] dumping events gets stuck in synchronise_sched

On Wed, 2010-08-18 at 08:40 +1000, Dave Chinner wrote:

> > When the systems locks up, I assume you want to see why? The trace_pipe
> > should show that without locking the system.
> 
> Exactly.

So it did work?

> 
> > You could also try downloading trace-cmd and running the tracer with
> > that. That will save all traces to a file while running the trace.
> 
> I don't have tens of GB available to store all the traces that an
> xfstests test run generates. In general, I don't need the traces,
> either, and when  I do the problem is usually in the current ring
> buffer, which is why I typically dump the events after the fact.

Note, you can also use: trace-cmd extract

which will extract the data from the ring buffer after the fact.

The resulting file ("trace.dat" by default) would allow you to read it
via kernelshark, or use the trace-cmd filters on it as well.

> 
> If the trace file cannot be made to handle this type of use
> robustly, then perhaps it should be removed...

You mean because it uses synchronize_sched() it should be removed? Seems
that it was another kernel bug that caused the issue.

I find the trace file nice to use, to look at a file over and over
again. I could just cat trace_pipe into another file and look at that
too I suppose. But I don't find this reason as rational to remove it.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ