linux-kernel - Re: [RFC PATCH] perf tools: Don't set inherit bit for system wide evsel

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]

Message-Id: <3E5B2C7C-BD19-4B61-AEDC-D1E2CFE0D7D2@163.com>
Date:	Fri, 23 Oct 2015 21:58:20 +0800
From:	pi3orama <pi3orama@....com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:	Wang Nan <wangnan0@...wei.com>, linux-kernel@...r.kernel.org,
	Alexei Starovoitov <ast@...mgrid.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Li Zefan <lizefan@...wei.com>
Subject: Re: [RFC PATCH] perf tools: Don't set inherit bit for system wide evsel



发自我的 iPhone

> 在 2015年10月23日，下午9:51，Arnaldo Carvalho de Melo <acme@...nel.org> 写道：
> 
> Em Fri, Oct 23, 2015 at 10:43:49AM +0000, Wang Nan escreveu:
>> Inherit bit is useless for a system wide evsel [1]. Further kernel
>> improvements are giving more constrain [2] on inherit events. This
>> patch set inherit bit to 0 to avoid potential constrains.
>> 
>> [1] http://lkml.kernel.org/r/20151022124142.GQ17308@twins.programming.kicks-ass.net
>> [2] http://lkml.kernel.org/r/1445559014-4667-1-git-send-email-ast@kernel.org
>> 
>> Signed-off-by: Wang Nan <wangnan0@...wei.com>
>> Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
>> Cc: Alexei Starovoitov <ast@...mgrid.com>
>> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
>> Cc: Li Zefan <lizefan@...wei.com>
>> Cc: pi3orama@....com
>> Link: http://lkml.kernel.org/n/ebpf-0tgilipxoo6fiebcxu3ft866@git.kernel.org
>> ---
>> 
>> evsel->system_wide doesn't correct reflect whether this evsel is system
>> wide or not, so checks pid when invoking perf_event_open, and it is
>> always correct.
> 
> Can't we do this at perf_evlist__config() or perf_evsel__config() time?

perf_evlist_config() is excluded because perf record doesn't use it.

> 
> We have record_opts at perf_evsel__config() time and I think we should
> leave changing the attr at perf_evsel__open() time for feature
> fallbacks, i.e. something we will only know when trying to use, which is
> different from this inherit-on-syswide case, that we know far in advance
> we will not need.

I tried to set this bit based on evsel->system_wide but it seems not reliable
as it should be, so I was wondering whether it is designed for other use. I will look
into this next week.

Thank you.
> 
> - Arnaldo
> 
>> ---
>> tools/perf/util/evsel.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
>> index 5566b16..e2d6c9a 100644
>> --- a/tools/perf/util/evsel.c
>> +++ b/tools/perf/util/evsel.c
>> @@ -1337,6 +1337,7 @@ retry_sample_id:
>> 
>>        for (thread = 0; thread < nthreads; thread++) {
>>            int group_fd;
>> +            struct perf_event_attr attr;
>> 
>>            if (!evsel->cgrp && !evsel->system_wide)
>>                pid = thread_map__pid(threads, thread);
>> @@ -1346,7 +1347,10 @@ retry_open:
>>            pr_debug2("sys_perf_event_open: pid %d  cpu %d  group_fd %d  flags %#lx\n",
>>                  pid, cpus->map[cpu], group_fd, flags);
>> 
>> -            FD(evsel, cpu, thread) = sys_perf_event_open(&evsel->attr,
>> +            attr = evsel->attr;
>> +            if (pid == -1)
>> +                attr.inherit = 0;
>> +            FD(evsel, cpu, thread) = sys_perf_event_open(&attr,
>>                                     pid,
>>                                     cpus->map[cpu],
>>                                     group_fd, flags);
>> -- 
>> 1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/