linux-kernel - Re: [PATCH 1/5] perf: Provide a proper stop action for software events

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:	Sat, 12 Jun 2010 18:25:55 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Zhang Yanmin <yanmin_zhang@...ux.intel.com>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 1/5] perf: Provide a proper stop action for software
	events

On Sat, Jun 12, 2010 at 11:43:11AM +0200, Peter Zijlstra wrote:
> On Sat, 2010-06-12 at 09:34 +0200, Frederic Weisbecker wrote:
> > In order to introduce new context exclusions, software events will
> > have to eventually stop when needed. We'll want perf_event_stop() to
> > act on every events.
> > 
> > To achieve this, remove the stub stop/start pmu callbacks of software
> > and tracepoint events that fixed a race in perf_adjust_period, and do
> > an explicit check to only reset the hardware event using the
> > start/stop callbacks.
> 
> I really object to this,. its just too ugly to live.


Several propositions of alternatives then, please tell me if one
looks more palatable to you:

- Having an argument on ->stop() and ->start() callback which
  would be reset_period. If reset_period is true, then the event
  knows the goal is to reprogram the interrupt.

  FWIW, that's my prefered solution, software pmus can just check
  this and return immediately. This avoids all the race between
  concurrent stat and stop plus the wasteful/useless hlist
  manipulation.

- Having a nesting level control on stop and start, so that
  we only call stop/start on nesting level 0. That solves the race.

- Having a flag in the pmu that tells if it wants to reprogram
  on period reset. Then we know if we need the start/stop against
  this flag. I just propose this one for the fun, I already
  know it sucks :)

Thanks.

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