linux-kernel - Re: [PATCH V3 7/7] arm64/perf: Enable branch stack sampling

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: <237ded55-5284-e30e-60e4-67db7799eedc@arm.com>
Date:   Tue, 11 Oct 2022 14:57:28 +0530
From:   Anshuman Khandual <anshuman.khandual@....com>
To:     Suzuki K Poulose <suzuki.poulose@....com>,
        James Clark <james.clark@....com>
Cc:     linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, peterz@...radead.org,
        acme@...nel.org, mark.rutland@....com, will@...nel.org,
        catalin.marinas@....com
Subject: Re: [PATCH V3 7/7] arm64/perf: Enable branch stack sampling



On 10/10/22 21:18, Suzuki K Poulose wrote:
> On 10/10/2022 14:55, James Clark wrote:
>>
>>
>> On 29/09/2022 08:58, Anshuman Khandual wrote:
>>> Now that all the required pieces are already in place, just enable the perf
>>> branch stack sampling support on arm64 platform, by removing the gate which
>>> blocks it in armpmu_event_init().
>>>
>>> Cc: Mark Rutland <mark.rutland@....com>
>>> Cc: Will Deacon <will@...nel.org>
>>> Cc: Catalin Marinas <catalin.marinas@....com>
>>> Cc: linux-kernel@...r.kernel.org
>>> Cc: linux-arm-kernel@...ts.infradead.org
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
>>> ---
>>>   drivers/perf/arm_pmu.c | 32 +++++++++++++++++++++++++++++---
>>>   1 file changed, 29 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
>>> index 93b36933124f..2a9b988b53c2 100644
>>> --- a/drivers/perf/arm_pmu.c
>>> +++ b/drivers/perf/arm_pmu.c
>>> @@ -537,9 +537,35 @@ static int armpmu_event_init(struct perf_event *event)
>>>           !cpumask_test_cpu(event->cpu, &armpmu->supported_cpus))
>>>           return -ENOENT;
>>>   -    /* does not support taken branch sampling */
>>> -    if (has_branch_stack(event))
>>> -        return -EOPNOTSUPP;
>>> +    if (has_branch_stack(event)) {
>>> +        /*
>>> +         * BRBE support is absent. Select CONFIG_ARM_BRBE_PMU
>>> +         * in the config, before branch stack sampling events
>>> +         * can be requested.
>>> +         */
>>> +        if (!IS_ENABLED(CONFIG_ARM_BRBE_PMU)) {
>>> +            pr_warn_once("BRBE is disabled, select CONFIG_ARM_BRBE_PMU\n");
>>> +            return -EOPNOTSUPP;
>>> +        }
>>> +
>>> +        if (event->attr.branch_sample_type & PERF_SAMPLE_BRANCH_KERNEL) {
>>> +            if (!perfmon_capable()) {
>>
>> I'm still getting different behaviour compared to x86 when using
>> perf_event_paranoid because of this perfmon_capable() call here.
> 
> Given the generic events framework already checks this for any
> privileged branch samples (i.e., for both KERNEL and HV), the
> individual drivers must not add additional restrictions.

Okay, will drop perfmon_capable() check here along with the warning.

> 
>>
>>> +                pr_warn_once("does not have permission for kernel branch filter\n");
>>
>> Also I was under the impression that this should be more like a
>> KERN_INFO loglevel rather than a KERN_WARNING. It's more like expected
>> behavior rather than unexpected behavior and as far as I know anyone who
>> sees something in dmesg might think something has gone wrong and try to
>> follow it up. It is quite a useful message but I remember getting a
>> review like this before and it made sense to me.
> 
> +1

Sure, will change remaining pr_warn_once() prints as pr_info() instead.