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]
Date:	Wed, 8 Oct 2014 16:20:28 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	Kevin Hilman <khilman@...nel.org>, ulf.hansson@...aro.org,
	linux-pm@...r.kernel.org, daniel.lezcano@...aro.org,
	rjw@...ysocki.net, linux-kernel@...r.kernel.org,
	Lina Iyer <lina.iyer@...aro.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 3/4] irq: Allow multiple clients to register for irq
 affinity notification

On Fri, 26 Sep 2014, Russell King - ARM Linux wrote:
> On Fri, Sep 26, 2014 at 11:29:56AM +0200, Thomas Gleixner wrote:
> > On Thu, 25 Sep 2014, Kevin Hilman wrote:
> > > Maybe I'm missing something, or maybe we're just lucky and nobody uses
> > > them together, but irq_set_affinity_notifier() only allows a single
> > > notifier to be registered at any given time.  So if you had a system
> > 
> > A single notifier per irq .....
> 
> So what about two drivers wanting to use this notifier, but sharing an
> interrupt?
> 
> It sounds to me like this notifier was misdesigned from the very start,
> and it should always have supported multiple notifiers.

Well, it was designed for a particular usecase which does not require
multiple notifiers. And we wanted it as simple as possible.

So while we could make it take multiple notifiers, it's just wrong for
the use case in question. QoS wants a system wide overview and not a
gazillion notifiers with life time issues etc.

So the proper solution is a general notifier, which gets called if any
interrupt affinity changes. That allows the QoS code or any other
interested party to gain a coherent per CPU knowledge.

That also avoid the whole lifetime issues of notifiers on interrupts,
when they are teared down and the descriptor gets freed. Of course
such a teardown or a simple disable_irq should inform the QoS code as
well so it knows that the CPU is not longer targeted by this
interrupt. Nothing we want to whack into a per irq notifier, really.

Thoughts?

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists