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: <YyBs1PJwNoNYv4NJ@sirena.org.uk>
Date:   Tue, 13 Sep 2022 12:43:16 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Anshuman Khandual <anshuman.khandual@....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, James Clark <james.clark@....com>,
        Rob Herring <robh@...nel.org>, Marc Zyngier <maz@...nel.org>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH V2 3/7] arm64/perf: Update struct pmu_hw_events for BRBE

On Tue, Sep 13, 2022 at 11:03:45AM +0530, Anshuman Khandual wrote:
> On 9/12/22 15:42, Mark Brown wrote:

> > like it would be clearer and safer to allocate these dynamically
> > when BRBE is used if that's possible, I'd expect that should also
> > deal with the stack frame size issues as well.

> That might not be possible because the generic 'struct perf_branch_stack'
> expects 'perf_branch_stack.entries' to be a variable array which is also
> contiguous in memory, with other elements in 'perf_branch_stack'. Besides
> that will be a deviation from similar implementations on x86 and powerpc
> platforms.

> The stack frame size came up because BRBE_MAX_ENTRIES is 64 compared to
> just 32 on other platforms, which follow the exact same method.

If this is a pattern used by other architectures and relied on by
the core that doesn't mean it's impossible to do anything, it
means that the existing code needs to be updated to allow the
larger number of entries for BRBE if we want to change things.
That is a lot of effort of course so something that moves the
allocation off the stack would be more expedient in the short
term.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ