Re: perf: prctl(PR_TASK_PERF_EVENTS_DISABLE) has no effect

[Ingo Molnar <mingo@elte.hu>]

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> > What's your concern with the prctl()? This would arguably be 
> > the right kind of usage for prctl(): it's an established 
> > API/ABI for process/task-wide settings.
> 
> Its doing things backwards, [...]

What does that mean?

> [...] also the whole concept of allowing people to hide things 
> from a profiler is so rotten I'm not willing to even consider 
> the notion.

But what we want here is not to hide things from the profiler, 
what we want to be able to is to *ask* the profiler to hide 
things for us, and we do that for a good reason.

This distinction (which I agree is important) could be 
implemented by adding a "allow self-profiling" bit (default 
disabled) in the perf_attr. That way such code would not be able 
to 'hide' from a simple:

  perf top
  perf record -a

session, but would be able to self-profile from such a session:

  perf record --allow-self-profile ...

where there could be some easy shortcut for 
--allow-self-profile, such as:

  perf record -S

that way no code could ever hide from a profiler, only if the 
profiler is specifically allowing self-profiling. (opt in)

The librarization you suggested might make sense too - but i 
think people will gravitate towards the easier to use variant, 
and prctl() is as easy and straightforward as it gets.

We can Cc: it to Linus with an explicit [RFC] and he can shoot 
it down if the API is ugly - but I don't think it's ugly.

Hm?

Thanks,

	Ingo