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: <1241508860.11059.24.camel@twins>
Date:	Tue, 05 May 2009 09:34:20 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, Paul Mackerras <paulus@...ba.org>
Subject: Re: perf_counter: resetting a event counter

On Tue, 2009-05-05 at 08:52 +0200, Ingo Molnar wrote:
> * Corey Ashford <cjashfor@...ux.vnet.ibm.com> wrote:
> 
> > Hi,
> >
> > In implementing the PAPI_reset function, whose purpose is to reset 
> > all of the counters in an event set, I found that [it appears] 
> > there is no straight-forward way to implement this function using 
> > "Performance Couunters for Linux".  My current implementation just 
> > closes the counters and reopens them again.  This is not a elegant 
> > solution, nor is the other alternative that occurred to me: 
> > maintain a "virtual" counter in user space, maintained using a 
> > base count, which is subtracted off of the current perf_counter 
> > value of a particular counter.
> >
> > Is there a way that I missed to reset an event counter?  If not, 
> > I'd like to request that a new ioctl command be added to support 
> > this ability.
> 
> We already have such ioctl actions:
> 
>         case PERF_COUNTER_IOC_ENABLE:
>         case PERF_COUNTER_IOC_DISABLE:
>         case PERF_COUNTER_IOC_REFRESH:
> 
> It would be a pretty natural addition to also have a reset method 
> there. Would you like to take a stab at it and send a patch? A 
> first-level approximation would be to do something like:
> 
> 	perf_counter_disable(counter);
> 	atomic64_set(&counter->count, 0);
> 	perf_counter_enable(counter);
> 
> btw, the reset code should probably take the counter->mutex lock as 
> well, because parallel resets done from multiple contexts are 
> otherwise not well-defined.

I would suggest simply bailing when the counter is active when trying to
reset if anything.

A plain: atomic64_set(&counter->count, 0), sounds attractive too.

The trouble with putting in those disable/enable calls is that you
cannot use the ioctl on an already disabled call, since it will
immediately enable it. Also, using it on an active counter is racy in
nature so the disable/enable cycle (or the proposed mutex) doesn't buy
you anything.


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