Messages in this thread | | | Date | Fri, 8 Jul 2022 15:31:59 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] perf/core: Add macros for possible sysctl_perf_event_paranoid values |
| |
On Fri, Jul 08, 2022 at 10:10:15AM +0100, James Clark wrote: > > > On 01/07/2022 07:39, Anshuman Khandual wrote: > > sysctl_perf_event_paranoid can have values from [-1, 0, 1, 2] which decides > > on perf event restrictions for unprivileged users. But using them directly > > makes it difficult to correlate exact restriction level they might impose. > > This just adds macros for those numerical restriction values, making them > > clear and improving readability. > > > > Cc: Peter Zijlstra <peterz@infradead.org> > > Cc: Ingo Molnar <mingo@redhat.com> > > Cc: Arnaldo Carvalho de Melo <acme@kernel.org> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: linux-perf-users@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> > > --- > > include/linux/perf_event.h | 22 ++++++++++++++++++---- > > kernel/events/core.c | 9 +-------- > > kernel/kallsyms.c | 3 ++- > > 3 files changed, 21 insertions(+), 13 deletions(-) > > > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h > > index da759560eec5..78156b9154df 100644 > > --- a/include/linux/perf_event.h > > +++ b/include/linux/perf_event.h > > @@ -1359,14 +1359,28 @@ int perf_event_max_stack_handler(struct ctl_table *table, int write, > > #define PERF_SECURITY_KERNEL 2 > > #define PERF_SECURITY_TRACEPOINT 3 > > > > +/* > > + * perf event paranoia level: > > + * -1 - not paranoid at all > > + * 0 - disallow raw tracepoint access for unpriv > > + * 1 - disallow cpu events for unpriv > > + * 2 - disallow kernel profiling for unpriv > > + */ > > +enum { > > + PERF_EVENT_DISALLOW_NONE = -1, > > + PERF_EVENT_DISALLOW_TRACE, > > + PERF_EVENT_DISALLOW_CPU, > > + PERF_EVENT_DISALLOW_KERNEL > > +}; > > + > > static inline int perf_is_paranoid(void) > > { > > - return sysctl_perf_event_paranoid > -1; > > + return sysctl_perf_event_paranoid > PERF_EVENT_DISALLOW_NONE; > > } > > > > Hi Anshuman, > > There are quite a few other instances of integers left in the tools code. > If you search for perf_event_paranoid_check() and perf_event_paranoid() > you will find them. > > I'm also wondering if it makes sense to return your new enum from all of > the helper functions instead of an int and make it explicit that it's > an instance of this new type? Although the compiler doesn't seem to warn > about using integers so maybe it's not worth doing this.
so I don't see the point of all this; it's already wrapped in these helper functions that have a descriptive name, why do we need more muck on top?
| |