linux-kernel - Re: [RFT v2 01/24] irqdomain: Introduce new interfaces to support hierarchy irqdomains

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:	Tue, 30 Sep 2014 23:49:15 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Abel <wuyun.wu@...wei.com>
cc:	Jiang Liu <jiang.liu@...ux.intel.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Borislav Petkov <bp@...en8.de>,
	Grant Likely <grant.likely@...aro.org>,
	Marc Zyngier <marc.zyngier@....com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tony Luck <tony.luck@...el.com>,
	Joerg Roedel <joro@...tes.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, linux-acpi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFT v2 01/24] irqdomain: Introduce new interfaces to support
 hierarchy irqdomains

On Tue, 30 Sep 2014, Abel wrote:
> On 2014/9/29 23:53, Thomas Gleixner wrote:
> What I suggest is something like:
> 
> for (iter = domain; iter; iter = iter->parent) {
> 	ret = iter->ops->alloc(iter, virq, nr_irqs, arg);
> 	if (ret < 0) {
> 		mutex_unlock(&irq_domain_mutex);
> 		goto out_free_irq_data;
> 	}
> }
> 
> in this way, the core infrastructure guarantees allocating down the
> irqdomain hierarchy, and the implementers of domain_ops->alloc()
> need not to call irq_domain_alloc_irqs_parent() any longer, just do
> the things they have to.

That makes sense. I misunderstood you then.

> > So we cannot define upfront how deep an ack/mask/unmask/... has to be
> > propagated down the chain. This needs a careful consideration in terms
> > of functionality and we want to be able to do performance shortcuts as
> > well.
> > 
> 
> Yes, I got it. And one more thing I concerned is that when hierarchy
> irqdomains is enabled, shouldn't the ack_parent() be called by default
> by the irqchip->irq_ack() of each domain to ensure all the domains in
> the delivery path ack this interrupt?

In the pure theory of design, yes. But that will cause pointless
overhead on particular systems.

On a particular system the ack of the top level domain C, i.e. the one
which is facing the device and is handled by the core irq flow
handler, might be enough because B does not require an ack and A is
implicitely acked by iret or some other magic instruction in the low
level entry path. And because we know that C can only be on top of B
and B is on top of A we want the flexibility to avoid going down the
full chain for nothing in the interrupt hot path.

So yes, in theory it should go down all levels, but in practice we
dont want to enforce it :)

Thanks,

	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/