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, 24 Mar 2011 14:22:21 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Lin Ming <ming.m.lin@...el.com>,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -tip] perf, x86: P4 PMU - Add missing read of a counter
 before test

On Thu, Mar 24, 2011 at 07:46:40PM +0300, Cyrill Gorcunov wrote:
> >> The read of a proper MSR register was missed so instead of a counter the 
> >> configration register is tested (it has ARCH_P4_UNFLAGGED_BIT always cleared) 
> >> and unflagged overflows never have been catched. Fix it by reading a proper 
> >> MSR register.
> > 
> > So what effect does this have on the regular perf user? Please try to describe 
> > the real-life effect of the bug/problem fixed here.
> > 
> > Thanks,
> > 
> > 	Ingo
> 
> Unflagged overflows never have been catched due to missed read of a register which
> is to signalize about it, and as result unknown nmi may happen leading to
> "Dazen and confused" message. That is what supposed to be in changelog?

I think Ingo is looking for something like this:

When an NMI happens on a P4, the perf nmi handler checks the configuration
register to see if the overflow bit is set or not before taking
appropriate action.  Unfortunately, various P4 machines had a broken
overflow bit, so a backup mechanism was implemented.  This mechanism
checked to see if the counter rolled over or not.

A previous commit that implemented this backup mechanism was broken.
Instead of reading the counter register, it used the configuration
register to determine if the counter rolled over or not.  Reading that bit
would give incorrect results.

This would lead to 'Dazed and confused' messages for the end user when
using the perf tool (or if the nmi watchdog is running).

The fix is to read the counter register before determining if the counter
rolled over or not.

Cheers,
Don
--
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