linux-kernel - Re: [PATCH v6 00/15] arm64: Self-hosted trace related errata workarounds

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 21 Oct 2021 22:42:12 +0100
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     Mathieu Poirier <mathieu.poirier@...aro.org>,
        Will Deacon <will@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Mike Leach <mike.leach@...aro.org>,
        Leo Yan <leo.yan@...aro.org>, Marc Zyngier <maz@...nel.org>,
        Coresight ML <coresight@...ts.linaro.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 00/15] arm64: Self-hosted trace related errata
 workarounds

Hi Mathieu,

On 21/10/2021 18:11, Mathieu Poirier wrote:
> On Thu, 21 Oct 2021 at 10:47, Will Deacon <will@...nel.org> wrote:
>>
>> Hi Mathieu,
>>
>> [CC Greg]
>>
>> On Thu, Oct 21, 2021 at 10:35:31AM -0600, Mathieu Poirier wrote:
>>> On Thu, Oct 21, 2021 at 09:53:14AM +0100, Will Deacon wrote:
>>>> On Wed, Oct 20, 2021 at 09:42:07AM -0600, Mathieu Poirier wrote:
>>>>> On Tue, Oct 19, 2021 at 05:31:38PM +0100, Suzuki K Poulose wrote:
>>>>>> Suzuki K Poulose (15):
>>>>>>    arm64: Add Neoverse-N2, Cortex-A710 CPU part definition
>>>>>>    arm64: errata: Add detection for TRBE overwrite in FILL mode
>>>>>>    arm64: errata: Add workaround for TSB flush failures
>>>>>>    arm64: errata: Add detection for TRBE write to out-of-range
>>>>>>    coresight: trbe: Add a helper to calculate the trace generated
>>>>>>    coresight: trbe: Add a helper to pad a given buffer area
>>>>>>    coresight: trbe: Decouple buffer base from the hardware base
>>>>>>    coresight: trbe: Allow driver to choose a different alignment
>>>>>>    coresight: trbe: Add infrastructure for Errata handling
>>>>>>    coresight: trbe: Workaround TRBE errata overwrite in FILL mode
>>>>>>    coresight: trbe: Add a helper to determine the minimum buffer size
>>>>>>    coresight: trbe: Make sure we have enough space
>>>>>>    coresight: trbe: Work around write to out of range
>>>>>>    arm64: errata: Enable workaround for TRBE overwrite in FILL mode
>>>>>>    arm64: errata: Enable TRBE workaround for write to out-of-range
>>>>>>      address
>>>>>>
>>>>>>   Documentation/arm64/silicon-errata.rst       |  12 +
>>>>>>   arch/arm64/Kconfig                           | 111 ++++++
>>>>>>   arch/arm64/include/asm/barrier.h             |  16 +-
>>>>>>   arch/arm64/include/asm/cputype.h             |   4 +
>>>>>>   arch/arm64/kernel/cpu_errata.c               |  64 +++
>>>>>>   arch/arm64/tools/cpucaps                     |   3 +
>>>>>>   drivers/hwtracing/coresight/coresight-trbe.c | 394 +++++++++++++++++--
>>>>>>   7 files changed, 567 insertions(+), 37 deletions(-)
>>>>>
>>>>> I have applied this set.
>>>>
>>>> Mathieu -- the plan here (which we have discussed on the list [1]) is
>>>> for the first four patches to be shared with arm64. Since you've gone
>>>> ahead and applied the whole series, please can you provide me a stable
>>>> branch with the first four patches only so that I can include them in
>>>> the arm64 tree?
>>>>
>>>> Failing that, I can create a branch for you to pull and apply the remaining
>>>> patches on top.
>>>>
>>>> Please let me know.
>>>
>>> Coresight patches flow through Greg's tree and as such the coresight-next tree
>>> gets rebased anyway.  I will remove the first 4 patches and push again.  By the
>>> way do you also want to pick up patches 14 and 16 since they are concerned with
>>> "arch/arm64/Kconfig" or should I keep them?
>>
>> I'll take the first 4 and put them on a stable branch, which you can choose
>> to pull if you like (but please don't rebase it or we'll end up with
>> duplicate commits). The rest of the patches, including the later Kconfig
>> changes, are yours but I doubt they'll apply cleanly without the initial
>> changes.
> 
> Right - I just had another look at them and what I suggested above won't work.
> 
>>
>> Are you sure Greg rebases everything? That sounds a bit weird to me, as it
>> means it's impossible to share branches with other trees. How do you usually
>> handle this situation?
> 
> Greg applies the patches I send to him near the end of every cycle -
> see this one [1] as an example.  Unfortunately that way of working
> makes it hard to deal with patchsets such as this one.
> 
> To move forward you can either pick up this whole series (just add my
> RB to all the CS patches) or I start sending pull requests to Greg.

I don't think that may work well, as the CoreSight bits in the series
depend on what is in coresight/next. So this series can't be pulled
in to arm64 without what is already in coresight/next.

Suzuki