• Stephane Eranian's avatar
    perf record: Fix priv level with branch sampling for paranoid=2 · 4ec8d984
    Stephane Eranian authored
    Now that the default perf_events paranoid level is set to 2, a regular
    user cannot monitor kernel level activity anymore. As such, with the
    following cmdline:
    
      $ perf record -e cycles date
    
    The perf tool first tries cycles:uk but then falls back to cycles:u as
    can be seen in the perf report --header-only output:
    
      cmdline : /export/hda3/tmp/perf.tip record -e cycles ls
      event : name = cycles:u, , id = { 436186, ... }
    
    This is okay as long as there is way to learn the priv level was changed
    internally by the tool.
    
    But consider a similar example:
    
      $ perf record -b -e cycles date
      Error:
      You may not have permission to collect stats.
    
    Consider tweaking /proc/sys/kernel/perf_event_paranoid,
    which controls use of the performance events system by
    unprivileged users (without CAP_SYS_ADMIN).
    ...
    
    Why is that treated differently given that the branch sampling inherits the
    priv level of the first event in this case, i.e., cycles:u? It turns out
    that the branch sampling code is more picky and also checks exclude_hv.
    
    In the fallback path, perf record is setting exclude_kernel = 1, but it
    does not change exclude_hv. This does not seem to match the restriction
    imposed by paranoid = 2.
    
    This patch fixes the problem by forcing exclude_hv = 1 in the fallback
    for paranoid=2. With this in place:
    
      $ perf record -b -e cycles date
        cmdline : /export/hda3/tmp/perf.tip record -b -e cycles ls
        event : name = cycles:u, , id = { 436847, ... }
    
    And the command succeeds as expected.
    
    V2 fix a white space.
    
    Committer testing:
    
    After aplying the patch we get:
    
      [acme@quaco ~]$ perf record -b -e cycles date
      WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted,
      check /proc/sys/kernel/kptr_restrict and /proc/sys/kernel/perf_event_paranoid.
    
      Samples in kernel functions may not be resolved if a suitable vmlinux
      file is not found in the buildid cache or in the vmlinux path.
    
      Samples in kernel modules won't be resolved at all.
    
      If some relocation was applied (e.g. kexec) symbols may be misresolved
      even with a suitable vmlinux or kallsyms file.
    
      Mon 23 Sep 2019 11:00:59 AM -03
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.005 MB perf.data (14 samples) ]
      [acme@quaco ~]$ perf evlist -v
      cycles:u: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|PERIOD|BRANCH_STACK, read_format: ID, disabled: 1, inherit: 1, exclude_kernel: 1, exclude_hv: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1, branch_sample_type: ANY
      [acme@quaco ~]$
    
    That warning about restricted kernel maps will be suppressed in a follow
    up patch, as perf_event_attr.exclude_kernel is set, i.e. no samples for
    the kernel will be taken and thus no need for those maps.
    Signed-off-by: default avatarStephane Eranian <eranian@google.com>
    Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
    Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lore.kernel.org/lkml/20190920230356.41420-1-eranian@google.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
    4ec8d984
evsel.c 68.5 KB