linux-kernel - Re: perf: another perf

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:	Mon, 11 May 2015 17:19:28 -0400 (EDT)
From:	Vince Weaver <vincent.weaver@...ne.edu>
To:	Stephane Eranian <eranian@...gle.com>
cc:	Vince Weaver <vincent.weaver@...ne.edu>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...hat.com>,
	Paul Mackerras <paulus@...ba.org>
Subject: Re: perf: another perf_fuzzer generated lockup

On Fri, 8 May 2015, Stephane Eranian wrote:

> Vince,
> 
> On Thu, May 7, 2015 at 9:40 PM, Vince Weaver <vincent.weaver@...ne.edu> wrote:
> >
> >
> > This is a new one I think, I hit it on the haswell machine running
> > 4.1-rc2.
> >
> > The backtrace is complex enough I'm not really sure what's going on here.
> >
> > The fuzzer has been having weird issues where it's been getting
> > overflow signals from invalid fds.  This seems to happen
> > when an overflow signal interrupts the fuzzer mid-fork?
> > And the fuzzer code doesn't handle this well and attempts to call exit()
> > and/or kill the child from the signal handler that interrupted the
> > fork() and that doesn't always go well.  I'm not sure if this is related,
> > just that some of those actions seem to appear in the backtrace.
> >
> >
> Is there a way to figure out how the fuzzer had programmed the PMU
> to get there? (besides adding PMU state dump in the kernel crashdump)?

Not easily.  In theory the fuzzer can regenerate state from the random 
seed, but some of these bugs seem to be timing related or race conditions, 
so they don't always replicate.  

Also I can make the fuzzer dump the state, but often it has 100+ events 
active and no way of knowing which ones are currently scheduled onto the 
CPU.

Dumping the PMU state might help, but at the same time there's all the 
other events going on such as software and tracepoint events and they 
might all be contributing.

This particular bug almost replicates; the system definitely pauses for a 
bit even if not long enough to trigger the watchdog.

I've been meaning to work on it more but we just finished with finals so I'm 
stuck doing more or less nothing but grading this next week.  After that I 
should have some time to work on this issue plus a couple other warnings 
the fuzzer has been showing.

Vince
--
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/