linux-kernel - Re: [PATCH] perf: Add irq and exception return branch types

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 8 Mar 2022 08:50:50 +0530
From:   Anshuman Khandual <anshuman.khandual@....com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        James Clark <james.clark@....com>
Cc:     linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Will Deacon <will@...nel.org>,
        linux-arm-kernel@...ts.infradead.org,
        linux-perf-users@...r.kernel.org
Subject: Re: [PATCH] perf: Add irq and exception return branch types



On 3/6/22 00:34, Arnaldo Carvalho de Melo wrote:
> Em Mon, Feb 28, 2022 at 03:45:25PM +0000, James Clark escreveu:
>>
>> On 24/02/2022 05:36, Anshuman Khandual wrote:
>>> This expands generic branch type classification by adding two more entries
>>> there in i.e irq and exception return. Also updates the x86 implementation
>>> to process X86_BR_IRET and X86_BR_IRQ records as appropriate. This changes
>>> branch types reported to user space on x86 platform but it should not be a
>>> problem. The possible scenarios and impacts are enumerated here.
>>>
>>> --------------------------------------------------------------------------
>>> | kernel | perf tool |                     Impact                        |
>>> --------------------------------------------------------------------------
>>> |   old  |    old    |  Works as before                                  |
>>> --------------------------------------------------------------------------
>>> |   old  |    new    |  PERF_BR_UNKNOWN is processed                     |
>>> --------------------------------------------------------------------------
>>> |   new  |    old    |  PERF_BR_ERET/IRQ are blocked via old PERF_BR_MAX |
>>> --------------------------------------------------------------------------
>>> |   new  |    new    |  PERF_BR_ERET/IRQ are recognized                  |
>>> --------------------------------------------------------------------------
>>>
>>> When PERF_BR_ERET/IRQ are blocked via old PERF_BR_MAX (new kernel with old
>>> perf tool) the user space might throw up an warning complaining about some
>>> unrecognized branch types being reported, but it is expected. PERF_BR_ERET
>>> and PERF_BR_IRQ branch types will be used for BRBE implementation on arm64
>>> platform.
>>>
>>> Cc: Peter Zijlstra <peterz@...radead.org>
>>> Cc: Ingo Molnar <mingo@...hat.com>
>>> Cc: Arnaldo Carvalho de Melo <acme@...nel.org>
>>> Cc: Mark Rutland <mark.rutland@....com>
>>> Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
>>> Cc: Jiri Olsa <jolsa@...hat.com>
>>> Cc: Namhyung Kim <namhyung@...nel.org>
>>> Cc: Thomas Gleixner <tglx@...utronix.de>
>>> Cc: Will Deacon <will@...nel.org>
>>> Cc: linux-arm-kernel@...ts.infradead.org
>>> Cc: linux-perf-users@...r.kernel.org
>>> Cc: linux-kernel@...r.kernel.org
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
>>> ---
>>> This applies on v5.17-rc5
>>>
>>> These two new branch types expands generic branch type classification but
>>> still leaves another three entries in 'type' field for later. Please refer
>>> a previous discussion [1] for some further context.
>>>
>>> [1] https://lore.kernel.org/all/1643348653-24367-1-git-send-email-anshuman.khandual@arm.com/
>>>
>>>  arch/x86/events/intel/lbr.c           | 4 ++--
>>>  include/uapi/linux/perf_event.h       | 2 ++
> Please try to avoid lockstep development of kernel and tools/, submit
> patches to the kernel maintainers for the kernel parts, and to the perf
> tools maintainer in separate patches.

Sure, will split this patch into two i.e kernel and user space changes. I have
an updated series which has some more kernel and user space API changes. But I
am wondering if there should be just a single patch updating user space API for
all the preceding kernel changes, or there should be one user space API patch
for each corresponding kernel change ?

> 
> It is important that changes to the API are flagged, for instance via
> tools/perf/check-headers.sh so that opportunity is given for the various
> people involved in perf (u/k) development to see what is going on.

Will run the diff after the series has been applied to demonstrate all the API
changes and update that in the cover letter.