linux-kernel - Re: [PATCH] armpmu: broadcast overflow irq on multi-core system having one muxed SPI for PMU.

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: <20180511103901.osi5lckq55jrms64@lakrids.cambridge.arm.com>
Date:   Fri, 11 May 2018 11:39:01 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     ��ȣ�� <hoeun.ryu@....com>
Cc:     'Hoeun Ryu' <hoeun.ryu@....com.com>,
        'Will Deacon' <will.deacon@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] armpmu: broadcast overflow irq on multi-core system
 having one muxed SPI for PMU.

On Fri, May 11, 2018 at 08:20:49AM +0900, ��ȣ�� wrote:
> Thank you for the reply.
> 
> > -----Original Message-----
> > From: Mark Rutland [mailto:mark.rutland@....com]
> > Sent: Thursday, May 10, 2018 7:21 PM
> > To: Hoeun Ryu <hoeun.ryu@....com.com>
> > Cc: Will Deacon <will.deacon@....com>; Hoeun Ryu <hoeun.ryu@....com>;
> > linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org
> > Subject: Re: [PATCH] armpmu: broadcast overflow irq on multi-core system
> > having one muxed SPI for PMU.

> > Muxing the PMU IRQs is a really broken system design, and there's no good
> > way of supporting it.

> > What we should do for such systems is:
> > 
> > * Add a flag to the DT to describe that the IRQs are muxed, as this
> >   cannot be probed.
> > 
> > * Add hrtimer code to periodically update the counters, to avoid
> >   overflow (e.g. as we do in the l2x0 PMU).
> > 
> > * Reject sampling for such systems, as this cannot be done reliably or
> >   efficiently.
> > 
> > NAK to broadcasting the IRQ -- there are a number of issues with the
> > general approach.
> 
> The second solution would be good if sampling is necessary even like those
> systems.

Please note that I mean *all* of the above. There would be no sampling
on systems with muxed PMU IRQs, since there's no correlation between
overflow events and the hrtimer interrupts -- the results of sampling
would be misleading.

> Actually I'm working on FIQ available ARM32 system and trying to enable the
> hard lockup detector by routing the PMU IRQ to FIQ.
> Because of that, I really need the interrupt event if it is a muxed SPI,
> beside I also need to make an dedicated IPI FIQ to broadcast the IRQ in
> this approach.
> What would you do if you were in the same situation ?

I don't think that this can work with a muxed IRQ, sorry.

It would be better to use some kind of timer.

[...]

> > Futher, If you ever encounter a case where you need to avoid preemption
> > across enabling IRQs, preemption must be disabled *before* enabling IRQs.
> 
> Ah, OK.
> Enabling IRQs can cause scheduling tasks in the end of exception or other
> scheduling points, right ?

Yes. If an IRQ was taken *between* enabling IRQs and disabling
preemption, preemption may occur as part of the exception return.

Thanks,
Mark.