linux-kernel - Re: perf timechart broken

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] [day] [month] [year] [list]

Message-Id: <201101171150.05444.trenn@suse.de>
Date:	Mon, 17 Jan 2011 11:50:04 +0100
From:	Thomas Renninger <trenn@...e.de>
To:	David Ahern <daahern@...co.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Ingo Molnar <mingo@...e.hu>, linux-perf-users@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: perf timechart broken

On Friday 14 January 2011 18:09:05 David Ahern wrote:
> 
> On 01/14/11 10:00, Thomas Renninger wrote:
> >> http://www.mail-archive.com/linux-perf-
> > users@...r.kernel.org/msg00057.html
> > Looks slightly different, the segfault should happen in:
> > process_sample_event
> > But looks very much related, possibly it has not been made/make with 
> > DEBUG=1
> > and -O6 was added and the backtrace is not 100% correct?
> 
> perf was built with DEBUG=1; that's how I got the pretty backtrace
> versus having the arguments optimized out. The cpu=6291457 is the
> garbage causing the segfault
Then it's the same issue.

> (there are only 2 cores in the system).
> 6291457 = 0x600001. Perhaps a mask is missing?
No, the power_start and power_end event have different kernel
structures, but in builtin-timechart.c the same struct is used.
cpu is at the end.
Therefore pe->cpu_id (in power_end case) accesses uninitialized
data.

But using the cpu data from the event itself (data.cpu, the cpu on
which the event got emited) for fixing this is fine.
It's the way it was done before the bug got introduced.
As said, this won't work if the kernel code triggering the C-state
is executed on a different CPU than the CPU which is affected by
the C-state change. But such HW does not yet exist on X86 afaik and the
power_start event dies out anyway.

I resubmitted the fix for 2.6.3{6,7} stable kernels and added you
to CC.

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