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: <b8ff5062-6477-01a2-b626-1ea3c286d272@linux.intel.com>
Date:   Mon, 10 Jul 2017 22:06:21 +0800
From:   "Jin, Yao" <yao.jin@...ux.intel.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Segher Boessenkool <segher@...nel.crashing.org>
Cc:     Michael Ellerman <mpe@...erman.id.au>, acme@...nel.org,
        jolsa@...nel.org, mingo@...hat.com,
        alexander.shishkin@...ux.intel.com, kan.liang@...el.com,
        ak@...ux.intel.com, linuxppc-dev@...ts.ozlabs.org,
        Linux-kernel@...r.kernel.org, yao.jin@...el.com
Subject: Re: [PATCH v6 1/7] perf/core: Define the common branch type
 classification



On 7/10/2017 9:46 PM, Peter Zijlstra wrote:
> On Mon, Jul 10, 2017 at 08:10:50AM -0500, Segher Boessenkool wrote:
>
>>> PERF_BR_INT is triggered by instruction "int" .
>>> PERF_BR_IRQ is triggered by interrupts, traps, faults (the ring 0,3
>>> transition).
>> So your "PERF_BR_INT" is a system call?
> The "INT" thing has indeed been used as system call mechanism (typically
> INT 80). But these days we have special purpose syscall instructions.
>
> It could maybe be compared to the PPC "Unconditional TRAP with
> immediate" where you use the immediate value as an index into a handler
> vector.
>
>> And PERF_BR_IRQ is not an interrupt request (as its name suggests),
>> not what we call an "external interrupt" either; instead it is every
>> interrupt that is not a system call?
> It is actual interrupts, but also faults, traps and all the other
> exceptions not caused by "INT" I think.
>
Yes. It's interrupt, traps, faults. If from is in the user space and to 
is in the kernel, it indicates the ring3 -> ring0 transition.

If the from instruction is not syscall or other ring transition 
instruction, it should be interrupt, traps and faults. That's how we get 
the PERF_BR_IRQ on x86.

Anyway, maybe we just use a minimum but the most common set of branch 
types now, it could be a good start and acceptable on all architectures.

PERF_BR_COND        = 1,    /* conditional */
PERF_BR_UNCOND        = 2,    /* unconditional */
PERF_BR_IND        = 3,    /* indirect */
PERF_BR_CALL        = 4,    /* call */
PERF_BR_IND_CALL    = 5,    /* indirect call */
PERF_BR_RET        = 6,    /* return */

Thanks
Jin Yao

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ