linux-kernel - Re: 2.6.29-rc4 regression

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 Feb 2009 08:45:40 +0100
From:	Mike Galbraith <efault@....de>
To:	Tim Blechmann <tim@...ngt.org>
Cc:	Robert Richter <robert.richter@....com>,
	oprofile-list@...ts.sf.net, linux-kernel@...r.kernel.org
Subject: Re: 2.6.29-rc4 regression

On Mon, 2009-02-16 at 13:53 +0100, Tim Blechmann wrote:
> >>> still, I can not reproduce this with my tests with v2.6.29-rc4. The
> >>> regression on the systems I have runs fine on rc4. On the system you
> >>> have, is commit b99170288421c79f0c2efa8b33e26e65f4bb7fb8 the first bad
> >>> one? If so, I will split the patch into smaller pieces to find the
> >>> change that introduces the bug.
> >> i got revision df13b31c286b3e91c556167954eda088d90a4295 working, by not
> >> resetting the counter width:
> >>
> >> diff --git a/arch/x86/oprofile/op_model_ppro.c b/arch/x86/oprofile/op_model_ppro.c
> >> index 12e207a..f0e019d 100644
> >> --- a/arch/x86/oprofile/op_model_ppro.c
> >> +++ b/arch/x86/oprofile/op_model_ppro.c
> >> @@ -76,12 +76,14 @@ static void ppro_setup_ctrs(struct op_msrs const * const msrs)
> >>  			return;
> >>  	}
> >>  
> >> +#if 0
> >>  	if (cpu_has_arch_perfmon) {
> >>  		union cpuid10_eax eax;
> >>  		eax.full = cpuid_eax(0xa);
> >>  		if (counter_width < eax.split.bit_width)
> >>  			counter_width = eax.split.bit_width;
> >>  	}
> >> +#endif
> >>
> >>
> >> this tweak did not work on later kernels, that i tested, though, and i 
> >> haven't had time to look into it in more detail.
> 
> hm, i just tried to compile 2.6.28 with this patch applied, and there
> the NMIs are delivered correctly.
> 
> > Thanks Tim, on later kernels, is it the behaviour you mentioned that
> > no NMIs are delivered and you do not receive any NMI?
> 
> on the current 2.6.29-rc5, no NMIs are delivered. however i have also
> applied the performance counter branch from tip, maybe that interferes
> with oprofile?

Hm.

If you're using latest tip, there _should_ be no interference.  There
was a problem a short while back in that both perfcounters and oprofile
register die handlers, but that was resolved by increasing oprofile's
handler priority, so that it takes over NMI handling while profiling.

I just did an oprofile test run with x86-tip/master while kerneltop was
running.  NMIs stopped being handled by kerneltop once oprofile started,
and resumed after oprofile finished... seems to be working.

	-Mike 

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