linux-kernel - Re: [PATCH 1/2] perf: dsu: Allow multiple devices share same IRQ.

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]

Message-ID: <5c1e81ff-467c-f2dc-4d92-f60117f67b40@arm.com>
Date:   Thu, 19 Mar 2020 16:12:43 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Mark Rutland <mark.rutland@....com>,
        Tuan Phan <tuanphan@...amperecomputing.com>
Cc:     patches@...erecomputing.com, Will Deacon <will@...nel.org>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/2] perf: dsu: Allow multiple devices share same IRQ.

On 2020-03-19 2:35 pm, Mark Rutland wrote:
> On Thu, Mar 19, 2020 at 02:32:51PM +0000, Mark Rutland wrote:
>> On Tue, Mar 17, 2020 at 05:26:15PM -0700, Tuan Phan wrote:
>>> Add IRQF_SHARED flag when register IRQ such that multiple dsu
>>> devices can share same IRQ.
>>>
>>> Signed-off-by: Tuan Phan <tuanphan@...amperecomputing.com>
>>
>> I don't think that this makes sense; further I think that this
>> highlights that the current driver doesn't support such a configuration
>> for other reasons.
>>
>> A DSU instance can only be accessed from a CPU associated with it, since
>> it's accessed via sysregs. The IRQ handler must run on one of those
>> CPUs.
>>
>> To handle that, the DSU PMU driver will need to gain an understanding of
>> which CPUs are associated with the instance. As it stands the driver
>> seems to assume that there's a single DSU instance, and that all CPUs
>> are affine to that same instance.
> 
> Sorry, I misread dsu_pmu_get_online_cpu_any_but(), multiple instances
> are handled already.

Oh, so either way it's effectively a rerun of the U8500 problem of 
having no guarantee that the interrupt will be taken on an appropriate 
CPU, and losing genuine events as apparently spurious if it isn't. Yeah, 
that's really really bad... :(

>> So NAK to this patch, given the above.
> 
> Regardless, this NAK stands.

Agreed, pretending that this might work without significantly more 
invasive workarounds does more harm than good.

Robin.