linux-kernel - Re: [PATCH] pinctrl-baytrail: workaround for irq descriptor conflict on ASUS T100TA

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, 23 Apr 2014 16:28:45 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Grant Likely <grant.likely@...aro.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>, Ingo Molnar <mingo@...e.hu>
Cc:	"Jin, Yao" <yao.jin@...ux.intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Krogerus, Heikki" <heikki.krogerus@...el.com>
Subject: Re: [PATCH] pinctrl-baytrail: workaround for irq descriptor conflict
 on ASUS T100TA

On Wed, Apr 23, 2014 at 1:35 PM, Mathias Nyman
<mathias.nyman@...ux.intel.com> wrote:

> The real issue to my understanding is that the x86 io-apic code is not
> really capable of living together with other interrupt controllers at the
> same time. There are some assumptions that interrupts 0-15 belong to the
> legacy ISA world, from there on we got io-apic PCI interrupts
> ( I think io-apic interrupt controller handles something like 24 - 48
> interrupts?) we want to be outside that range until this is fixed.
>
> The x86 io-apic code does nasty things, for example the function
> that allocates the irq and the private chip data assumes that if the irq
> descriptor is taken, (returns -EEXISTS) then io-apic just must have reserved
> it earlier and can anyway use it, and access the chip data in a format only
> io-apic (struct irq_cfg) uses. This is of course not the case if a gpio
> interrupt controller like pinctrl-baytrail reserved the interrupt descriptor
> earler.  -> oops
>
> here's the io_apic.c function:
>
> static struct irq_cfg *alloc_irq_and_cfg_at(unsigned int at, int node)
> {
>         int res = irq_alloc_desc_at(at, node);
>         struct irq_cfg *cfg;
>
>         if (res < 0) {
>                 if (res != -EEXIST)
>                         return NULL;
>                 cfg = irq_get_chip_data(at);
>                 if (cfg)
>                         return cfg;
>         }
>
>         cfg = alloc_irq_cfg(at, node);
>         if (cfg)
>                 irq_set_chip_data(at, cfg);
>         else
>                 irq_free_desc(at);
>         return cfg;
> }
>
> We tried to fix this particular issue (make sure the interrupt belongs to a
> io_apic controller before letting io_apic touch it), but we just opened a
> can of worms of other issues I don't know how to deal with.

This looks pretty scary.

io_apic.c is maintained by every single kernel bigshot and I sure
as hell would like to not under any circumstance step on its toes
so whatever solution we can think of until the next merge window
will be applied. (AFICT this affects all baytrails, no desktops etc).

However this is a first time for an embedded irqchip (coupled
with GPIO ACPI) creeping into the x86 world, so it needs some
attention I think, do we have a direction forward for peaceful
coexistence of several irq controllers picking some IRQ
numbers/descriptors dynamically as they probe, also on
x86 systems?

Other archs doesn't seem to have this problem, but they also
do not have the same legacy.

Yours,
Linus Walleij
--
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/