linux-kernel - Re: [PATCH] oprofile, x86: Fix race in nmi handler while starting

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]

Message-ID: <20110616152531.GR20052@erda.amd.com>
Date:	Thu, 16 Jun 2011 17:25:31 +0200
From:	Robert Richter <robert.richter@....com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	oprofile-list <oprofile-list@...ts.sourceforge.net>,
	"Suthikulpanit, Suravee" <Suravee.Suthikulpanit@....com>
Subject: Re: [PATCH] oprofile, x86: Fix race in nmi handler while starting

On 09.06.11 03:18:54, Ingo Molnar wrote:
> 
> * Robert Richter <robert.richter@....com> wrote:
> 
> > In some rare cases, nmis are generated immediately after the nmi 
> > handler of the cpu was started. This causes the counter not to be 
> > enabled. Before enabling the nmi handlers we need to set variable 
> > ctr_running first and make sure its value is written to memory.
> > 
> > Also, the patch makes all existing barriers a memory barrier 
> > instead of a compiler barrier only.
> 
> Could we *PLEASE* just do the obvious and turn oprofile into a perf 
> user on x86 too, like ARM already does? Two years down the line and 
> there's zero progress in that area. We want to obsolete the Oprofile 
> PMU bits on x86, the infrastructure duplication causes non-trivial 
> problems like this one.

Ingo,

I would rather prefer to spend the effort to add full pmu support to
perf. AMD features missing are still IBS and nb performance counters
for family 15h. The oprofile kernel driver would become obsolete at
all with a new daemon using the perf syscall interface. So why
spending more time with porting this legacy driver to perf in the
kernel? It will be also hard to implement identical behaviour which
may raise concerns about backward compatibility of the kernel driver.

I admit, we have had a lot of bug fixes for oprofile in the past, but
most of them are part of maintaining existing code which we have to do
for distros anyway. There is almost no or only limited feature
development for oprofile now.

Hope this makes sense.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

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