linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: James Clark <james.clark@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Rob Herring <robh@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, peterz@infradead.org,
	acme@kernel.org, mark.rutland@arm.com, will@kernel.org,
	catalin.marinas@arm.com
Subject: Re: [PATCH V2 0/7] arm64/perf: Enable branch stack sampling
Date: Tue, 13 Sep 2022 14:12:13 +0100	[thread overview]
Message-ID: <8d39eb33-3347-4fbd-bf72-9c8eaa756648@arm.com> (raw)
In-Reply-To: <14c0b04b-f9f0-632c-4813-f1952e3320bc@arm.com>



On 13/09/2022 13:12, Anshuman Khandual wrote:
> 
> 
> On 9/13/22 16:25, James Clark wrote:
>>
>> On 08/09/2022 06:10, Anshuman Khandual wrote:
>>> This series enables perf branch stack sampling support on arm64 platform
>>> via a new arch feature called Branch Record Buffer Extension (BRBE). All
>>> relevant register definitions could be accessed here.
>>>
>>> https://developer.arm.com/documentation/ddi0601/2021-12/AArch64-Registers
>>>
>>> This series applies on v6.0-rc4 after the BRBE related perf ABI changes series
>>> (V7) that was posted earlier, and a branch sample filter helper patch.
>>>
>>> https://lore.kernel.org/all/20220824044822.70230-1-anshuman.khandual@arm.com/
>>>
>>> https://lore.kernel.org/all/20220906084414.396220-1-anshuman.khandual@arm.com/
>>>
>>> Following issues have been resolved
>>>
>>> - Jame's concerns regarding permission inadequacy related to perfmon_capable()
>>> - Jame's concerns regarding using perf_event_paranoid along with perfmon_capable()
>> I don't see the resolution to this one. I'm not 100% sure of the code
>> path used for LBR, but I think you just need to take perf_allow_kernel()
>> into account somewhere to make this command have the same result with
>> BRBE. Is there any contention that the permissions shouldn't behave in
>> the same way across platforms? This is when perf_event_paranoid < 2:
>>
>> Intel:
>>
>>   $ perf record -j any -- ls
>>
>>   [ perf record: Woken up 1 times to write data ]
>>   [ perf record: Captured and wrote 0.014 MB perf.data (16 samples) ]
>>
>> Arm:
>>
>>   $ perf record -j any -- ls
>>
>>   Error:
>>   No permission to enable cycles event.
>>
> Proposed solution here just follows what we did for the SPE driver recently.
> I would not be surprised, if there is difference in semantics in permission
> checking across various platform perf drivers. 

SPE isn't too relevant because it's its own thing and there is no SPE
command that can be run on other platforms. There may be something like
perf c2c that uses SPE under the hood but if it works differently across
platforms I would also consider that a bug and not something to be copied.

> Ideally permission should not
> even be checked in platform drivers - either capability or perf_event_paranoid.

But it is currently. Users don't care about the code or how complicated
the implementation is, only that the behaviour is sane. We're not
helping Arm users or adoption of BRBE if the same command that someone
runs somewhere else fails inexplicably, without any justification other
than "the code didn't look right".

> 
> Unfortunately changing the permission checking framework across generic perf
> is beyond the scope for this BRBE proposal and might be taken up later via a

Permissions are definitely not beyond the scope of this proposal because
the code to check the permissions has been added right here:

  +		if (perfmon_capable())
  +			event->hw.flags |= ARMPMU_EVT_PRIV;

And all it needs extra is a check of perf_allow_kernel() or similar.

> different series. Although I would be willing to accommodate any alternate
> suggestions to improve permission checking here in the BRBE driver.

I don't think planning to change it in the future is very user friendly
either, otherwise any help we give to people stuck will have to start
with an explanation about how we changed the permissions model across
versions, and their command or setup also depends on the kernel version.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-09-13 13:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-08  5:10 [PATCH V2 0/7] arm64/perf: Enable branch stack sampling Anshuman Khandual
2022-09-08  5:10 ` [PATCH V2 1/7] arm64/perf: Add register definitions for BRBE Anshuman Khandual
2022-09-12  9:57   ` Mark Brown
2022-09-13  6:24     ` Anshuman Khandual
2022-09-13 11:30       ` Mark Brown
2022-09-08  5:10 ` [PATCH V2 2/7] arm64/perf: Update struct arm_pmu " Anshuman Khandual
2022-09-08  5:10 ` [PATCH V2 3/7] arm64/perf: Update struct pmu_hw_events " Anshuman Khandual
     [not found]   ` <202209082022.6BPdyQn8-lkp@intel.com>
2022-09-09  3:11     ` Anshuman Khandual
     [not found]   ` <202209082259.XDCTMY9g-lkp@intel.com>
2022-09-09  3:14     ` Anshuman Khandual
2022-09-12 10:12   ` Mark Brown
2022-09-13  5:33     ` Anshuman Khandual
2022-09-13 11:43       ` Mark Brown
2022-09-14  3:39         ` Anshuman Khandual
2022-09-14  9:35           ` Mark Brown
2022-09-08  5:10 ` [PATCH V2 4/7] driver/perf/arm_pmu_platform: Add support for BRBE attributes detection Anshuman Khandual
2022-09-08  5:10 ` [PATCH V2 5/7] arm64/perf: Drive BRBE from perf event states Anshuman Khandual
2022-09-08 15:31   ` kernel test robot
2022-09-08  5:10 ` [PATCH V2 6/7] arm64/perf: Add BRBE driver Anshuman Khandual
2022-09-08  9:23   ` kernel test robot
2022-09-08 10:16     ` Anshuman Khandual
2022-09-13 10:39   ` James Clark
2022-09-13 11:38     ` Anshuman Khandual
2022-09-08  5:10 ` [PATCH V2 7/7] arm64/perf: Enable branch stack sampling Anshuman Khandual
2022-09-13 10:55 ` [PATCH V2 0/7] " James Clark
2022-09-13 12:12   ` Anshuman Khandual
2022-09-13 13:12     ` James Clark [this message]
2022-09-14  4:43       ` Anshuman Khandual

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8d39eb33-3347-4fbd-bf72-9c8eaa756648@arm.com \
    --to=james.clark@arm.com \
    --cc=acme@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=robh@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).