linux-kernel - Re: [PATCH v2] perf: update perf_cgroup time for ancestor cgroup(s)

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:   Fri, 16 Mar 2018 15:24:47 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Song Liu <songliubraving@...com>
Cc:     linux-kernel@...r.kernel.org, jolsa@...hat.com, kernel-team@...com,
        ephiepark@...com
Subject: Re: [PATCH v2] perf: update perf_cgroup time for ancestor cgroup(s)

On Mon, Mar 12, 2018 at 09:59:43AM -0700, Song Liu wrote:
> When a perf_event is attached to parent cgroup, it should count events
> for all children cgroups:
> 
>  parent_group   <---- perf_event
>    \
>     - child_group  <---- process(es)
> 
> However, in our tests, we found this perf_event cannot report reliable
> results. Here is an example case:
> 
>   # create cgroups
>   mkdir -p /sys/fs/cgroup/p/c
>   # start perf for parent group
>   perf stat -e instructions -G "p"
> 
>   # on another console, run test process in child cgroup:
>   stressapptest -s 2 -M 1000 & echo $! > /sys/fs/cgroup/p/c/cgroup.procs
> 
>   # after the test process is done, stop perf in the first console shows
> 
>        <not counted>      instructions              p
> 
> The instruction should not be "not counted" as the process runs in the
> child cgroup.
> 
> We found this is because perf_event->cgrp and cpuctx->cgrp are not
> identical, thus perf_event->cgrp are not updated properly.
> 
> This patch fixes this by updating perf_cgroup properly for ancestor
> cgroup(s).
> 
> Signed-off-by: Song Liu <songliubraving@...com>
> Reported-by: Ephraim Park <ephiepark@...com>

Yeah, that looks about right, Thanks!