linux-kernel - Re: [PATCH RESEND] perf/core: Fix installing cgroup event into cpu

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:   Wed, 24 Jan 2018 15:29:34 +0800
From:   Lin Xiulei <linxiulei@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Jiri Olsa <jolsa@...hat.com>, mingo@...hat.com, acme@...nel.org,
        alexander.shishkin@...ux.intel.com, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, Stephane Eranian <eranian@...il.com>,
        torvalds@...ux-foundation.org, linux-perf-users@...r.kernel.org,
        Brendan Gregg <brendan.d.gregg@...il.com>,
        yang_oliver@...mail.com, jinli.zjl@...baba-inc.com,
        "leilei.lin" <leilei.lin@...baba-inc.com>
Subject: Re: [PATCH RESEND] perf/core: Fix installing cgroup event into cpu

yes, you are right. In my cases, there also are some issues in
add_event_to_ctx(),
I am gonna fix it at v2

Thanks

2018-01-24 0:37 GMT+08:00 Peter Zijlstra <peterz@...radead.org>:
> On Tue, Jan 23, 2018 at 12:13:06PM +0800, linxiulei@...il.com wrote:
>> From: "leilei.lin" <leilei.lin@...baba-inc.com>
>>
>> Do not install cgroup event into the CPU context if the cgroup
>> is not running on this CPU
>>
>> While there is no task of cgroup running specified CPU, current
>> kernel still install cgroup event into CPU context, that causes
>> another cgroup event can't be installed into this CPU.
>>
>> Signed-off-by: leilei.lin <leilei.lin@...baba-inc.com>
>> ---
>>  kernel/events/core.c | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>> index 4df5b69..19c587b 100644
>> --- a/kernel/events/core.c
>> +++ b/kernel/events/core.c
>> @@ -2284,6 +2284,7 @@ static int  __perf_install_in_context(void *info)
>>       struct perf_event_context *ctx = event->ctx;
>>       struct perf_cpu_context *cpuctx = __get_cpu_context(ctx);
>>       struct perf_event_context *task_ctx = cpuctx->task_ctx;
>> +     struct perf_cgroup *cgrp;
>>       bool reprogram = true;
>>       int ret = 0;
>>
>> @@ -2311,6 +2312,19 @@ static int  __perf_install_in_context(void *info)
>>               raw_spin_lock(&task_ctx->lock);
>>       }
>>
>> +     if (event->cgrp) {
>> +             /*
>> +              * Only care about cgroup events.
>> +              *
>> +              * If only the task belongs to cgroup of this event,
>> +              * we will continue the installment
>> +              */
>> +             cgrp = perf_cgroup_from_task(current, ctx);
>> +             if (!cgroup_is_descendant(cgrp->css.cgroup,
>> +                                     event->cgrp->css.cgroup))
>> +                     goto unlock;
>> +     }
>> +
>>       if (reprogram) {
>>               ctx_sched_out(ctx, cpuctx, EVENT_TIME);
>>               add_event_to_ctx(event, ctx);
>
> I think this is wrong. You're right in that we need not schedule it not,
> but the above also completely fails to add it to the context, leading to
> it never being scheduled ever.
>
> At the very least we should do add_event_to_ctx() on it.
>
> So the only thing you can do is pick 'reprogram' or not based on if the
> current cgrp is related to the event->ctx.