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:   Mon, 5 Mar 2018 15:55:54 -0500
From:   "Liang, Kan" <kan.liang@...ux.intel.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     mingo@...hat.com, linux-kernel@...r.kernel.org, jolsa@...hat.com,
        namhyung@...nel.org, wangnan0@...wei.com, ak@...ux.intel.com
Subject: Re: [PATCH 1/7] perf mmap: Store mmap scope and type in struct
 perf_mmap



On 3/5/2018 3:20 PM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Mar 05, 2018 at 02:10:53PM -0500, kan.liang@...ux.intel.com escreveu:
>> From: Kan Liang <kan.liang@...ux.intel.com>
>>
>> There are too many boilerplates for the perf_mmap__read*() interfaces.
>>
>> Some of the data (e.g. 'start', 'end', 'overwrite') should be stored in
>> struct perf_mmap at initialization. They will be used later.
>>
>> No functional change.
>>
>> Signed-off-by: Kan Liang <kan.liang@...ux.intel.com>
>> ---
>>   tools/perf/util/mmap.c | 11 ++++++++---
>>   tools/perf/util/mmap.h |  3 +++
>>   2 files changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
>> index 4f27c46..642b479 100644
>> --- a/tools/perf/util/mmap.c
>> +++ b/tools/perf/util/mmap.c
>> @@ -250,11 +250,14 @@ int perf_mmap__read_init(struct perf_mmap *md, bool overwrite,
>>   
>>   	*startp = overwrite ? head : old;
>>   	*endp = overwrite ? old : head;
> 
> Why did you keep the above and haven't removed the startp/endp args? 

The startp/endp are used by perf_mmap__read_event().
I don't want to make all the changes in a single patch. I think it's 
hard to review.
So I modified the interface one by one.
Only changing one interface will break the usage.
So the old 'startp/endp' and new 'md->start/md->end' will exist 
simultaneously in the first few patches. They have the same value.

Patch 1,3,4 add the new 'md->start/md->end' for the three interfaces.
Patch 2 uses the new 'md->start/md->end' for perf record.
Patch 5,6,7 remove the old 'startp/endp' for other perf tools/test and 
refine the interfaces.

Thanks,
Kan
> to
> ease the conversion somehow? I'll look at the other patches, but I think
> we should change the function signature here and in the callers all at
> once.
> 
> Sometimes this is ok, and probably this is one case.
> 
> - Arnaldo
> 
>> +	md->overwrite = overwrite;
>> +	md->start = overwrite ? head : old;
>> +	md->end = overwrite ? old : head;
>>   
>> -	if (*startp == *endp)
>> +	if (md->start == md->end)
>>   		return -EAGAIN;
>>   
>> -	size = *endp - *startp;
>> +	size = md->end - md->start;
>>   	if (size > (unsigned long)(md->mask) + 1) {
>>   		if (!overwrite) {
>>   			WARN_ONCE(1, "failed to keep up with mmap data. (warn only once)\n");
>> @@ -268,8 +271,10 @@ int perf_mmap__read_init(struct perf_mmap *md, bool overwrite,
>>   		 * Backward ring buffer is full. We still have a chance to read
>>   		 * most of data from it.
>>   		 */
>> -		if (overwrite_rb_find_range(data, md->mask, head, startp, endp))
>> +		if (overwrite_rb_find_range(data, md->mask, head, &md->start, &md->end))
>>   			return -EINVAL;
>> +		*startp = md->start;
>> +		*endp = md->end;
>>   	}
>>   
>>   	return 0;
>> diff --git a/tools/perf/util/mmap.h b/tools/perf/util/mmap.h
>> index ec7d3a24..9359e93 100644
>> --- a/tools/perf/util/mmap.h
>> +++ b/tools/perf/util/mmap.h
>> @@ -20,6 +20,9 @@ struct perf_mmap {
>>   	int		 fd;
>>   	refcount_t	 refcnt;
>>   	u64		 prev;
>> +	u64		 start;
>> +	u64		 end;
>> +	bool		 overwrite;
>>   	struct auxtrace_mmap auxtrace_mmap;
>>   	char		 event_copy[PERF_SAMPLE_MAX_SIZE] __aligned(8);
>>   };
>> -- 
>> 2.4.11

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ