linux-kernel - Re: [PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver

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: <20160825163805.GA8524@remoulade>
Date:   Thu, 25 Aug 2016 17:38:06 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Rich Felker <dalias@...c.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-sh@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        Marc Zyngier <Marc.Zyngier@....com>
Subject: Re: [PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver

On Thu, Aug 25, 2016 at 10:56:50AM -0400, Rich Felker wrote:
> On Thu, Aug 25, 2016 at 10:07:08AM +0200, Thomas Gleixner wrote:
> > On Wed, 24 Aug 2016, Rich Felker wrote:
> As for this topic, what happened is that, after the first and second
> time of expressing confusion about how the infrastructure did not make
> sense and whether I should even be using it, I did not get anything
> resembling an explanation of why it's the way it is or why I might be
> wrong in thinking it's a bug, and so I went forward with the
> assumption that is was just a bug. Now that Mark Rutland has explained
> it well (and with your additional explanation below in your email), I
> see what the motivation was, but I still think it could be done in a
> less-confusing and more-consistent way that doesn't assume ARM-like
> irq architecture.

The fun this is that right until the point you sent this patch, it was
consistent for all hardware that we support and were aware of. For others, it
is your hardware that is the confusing case. ;)

In future, it's better to state 'this doesn't seem to match my hardware' rather
than 'this is misdesigned'. Ideally, with a description of how your hardware
works, as that's the thing no-one else is familiar with.

> > If your particular hardware has the old scheme of seperate interrupt numbers
> > for per cpu interrupts, then you can simply use the normal interrupt scheme
> > and request a seperate interrupt per cpu.
> 
> Nominally it uses the same range of hardware interrupt numbers for all
> (presently both) cpus, but some of them get delivered to a specific
> cpu associated with the event (presently, IPI and timer; IPI is on a
> fixed number at synthesis time but timer is runtime configurable)
> while others are conceptually deliverable to either cpu (presently
> only delivered to cpu0, but that's treated as an implementation
> detail).

Given you say it's delivered to the CPU associated with the event (and you have
different PIT bases per-cpu), it sounds like your timer interrupt is percpu,
it's just that the hwirq number can be chosen by software.

> It currently works requesting the irq with flags that ensure the
> handler runs on the same cpu it was delivered on, without using any
> other percpu irq framework. If you have concerns about ways this could
> break and want me to make the drivers do something else, I'm open to
> suggestions.

As I suggested, I don't think that this is right, and you need some mechanism
to describe to the kernel that the interrupt is percpu (e.g. a flag in the
interrupt-specifier in DT).

Thanks,
Mark.