linux-kernel - Re: [PATCH 1/6] perf_counter: move the event overflow output bits to record

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: <49D549E7.1040904@linux.vnet.ibm.com>
Date:	Thu, 02 Apr 2009 16:27:35 -0700
From:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC:	Ingo Molnar <mingo@...e.hu>, Paul Mackerras <paulus@...ba.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] perf_counter: move the event overflow output bits
 to record_type

Whoops, nevermind.

My misunderstanding on this one.  This enum is used for event type, not 
the record_type, and as such is makes sense for there to be exclusive 
mmap and munmap event records.

Thinking about this a bit, I'm guessing that the idea is to track the 
loading and unloading of shared objects which uses mmap and munmap, so 
that that the ip can be related to a particular object that was mapped 
in at the time of the counter overflow interrupt.  Is that right?

- Corey

Corey Ashford wrote:
> Peter Zijlstra wrote:
>> Per suggestion from Paul, move the event overflow bits to record_type
>> and sanitize the enums a bit.
>>
>> Breaks the ABI -- again ;-)
>>
> [snip]
> 
> With this patch, the definitions look like this now:
> 
> [snip]
> /*
>  * Bits that can be set in hw_event.record_type to request information
>  * in the overflow packets.
>  */
> enum perf_counter_record_format {
>         PERF_RECORD_IP          = 1U << 0,
>         PERF_RECORD_TID         = 1U << 1,
>         PERF_RECORD_GROUP       = 1U << 2,
>         PERF_RECORD_CALLCHAIN   = 1U << 3,
> };
> 
> [snip]
> enum perf_event_type {
> 
>         PERF_EVENT_MMAP                 = 1,
>         PERF_EVENT_MUNMAP               = 2,
> 
>         /*
>          * Half the event type space is reserved for the counter overflow
>          * bitfields, as found in hw_event.record_type.
>          *
>          * These events will have types of the form:
>          *   PERF_EVENT_COUNTER_OVERFLOW { | __PERF_EVENT_* } *
>          */
>         PERF_EVENT_COUNTER_OVERFLOW     = 1UL << 31,
>         __PERF_EVENT_IP                 = PERF_RECORD_IP,
>         __PERF_EVENT_TID                = PERF_RECORD_TID,
>         __PERF_EVENT_GROUP              = PERF_RECORD_GROUP,
>         __PERF_EVENT_CALLCHAIN          = PERF_RECORD_CALLCHAIN,
> };
> [snip]
> 
> 
> Unless I'm misreading something here, there's overlap in the enum values 
> of perf_event_type enum. PERF_EVENT_MMAP has the same value as 
> __PERF_EVENT_IP, and PERF_EVENT_MUNMAP has the same value as 
> __PERF_EVENT_TID.
> 
> Are these lower bits being reused when PERF_EVENT_COUNTER_OVERFLOW is 
> OR'd in, which would imply that PERF_EVENT_MMAP and PERF_EVENT_MUNMAP 
> are mutually exclusive with all of the PERF_EVENT_COUNTER_OVERFLOW values.
> 
> Actually, I don't really understand the purpose of the PERF_EVENT_MMAP 
> and PERF_EVENT_MUNMAP bits. My hazy understanding is that they are used 
> for finding the file, function and line number at overflow interrupt 
> time, but it's unclear to me what that has to do with mmap.  I'll go 
> back and try to find the relevant patch notes again.
> 
> - Corey
> 
> 
> 
> -- 
> 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/

-- 
Regards,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor@...ibm.com

--
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/