linux-kernel - Re: [PATCH 2/9] perf tools: Support the auxiliary event

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, 3 Feb 2021 16:20:38 -0500
From:   "Liang, Kan" <kan.liang@...ux.intel.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     mingo@...nel.org, linux-kernel@...r.kernel.org,
        peterz@...radead.org, eranian@...gle.com, namhyung@...nel.org,
        jolsa@...hat.com, ak@...ux.intel.com, yao.jin@...ux.intel.com,
        maddy@...ux.vnet.ibm.com
Subject: Re: [PATCH 2/9] perf tools: Support the auxiliary event



On 2/3/2021 3:02 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Feb 02, 2021 at 12:09:06PM -0800,kan.liang@...ux.intel.com  escreveu:
>> From: Kan Liang<kan.liang@...ux.intel.com>
>> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
>> index c26ea822..c48f6de 100644
>> --- a/tools/perf/util/evsel.c
>> +++ b/tools/perf/util/evsel.c
>> @@ -2689,6 +2689,9 @@ int evsel__open_strerror(struct evsel *evsel, struct target *target,
>>   		if (perf_missing_features.aux_output)
>>   			return scnprintf(msg, size, "The 'aux_output' feature is not supported, update the kernel.");
>>   		break;
>> +	case ENODATA:
>> +		return scnprintf(msg, size, "Cannot collect data source with the load latency event alone. "
>> +				 "Please add an auxiliary event in front of the load latency event.");
> Are you sure this is the only case where ENODATA comes out from
> perf_event_open()? Well, according to your comment in:
> 
>    61b985e3e775a3a7 ("perf/x86/intel: Add perf core PMU support for Sapphire Rapids")
> 
> It should be at that point in time, so its safe to merge as-is, but then
> I think this is fragile, what if someone else, in the future, not
> knowing that ENODATA is supposed to be used only with that ancient CPU,
> Sapphire Rapids, uses it?:-)
> 
> Please consider adding a check before assuming ENODATA is for this
> specific case.

Sure, I will add a check in V2.

Thanks,
Kan