Messages in this thread | | | Date | Mon, 11 Jul 2022 14:55:12 +0530 | Subject | Re: [PATCH] perf/core: Add macros for possible sysctl_perf_event_paranoid values | From | Anshuman Khandual <> |
| |
On 7/8/22 19:01, Peter Zijlstra wrote: > 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?
Enumerating [-1, 0, 1, 2] paranoid range values in kernel too, does not add much value as well ?
| |