linux-kernel - Re: [PATCH] irq: handle irq0 special only on x86

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: <20091210082452.GA2420@pengutronix.de>
Date:	Thu, 10 Dec 2009 09:24:52 +0100
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	David Miller <davem@...emloft.net>
Cc:	xiyou.wangcong@...il.com, x86@...nel.org,
	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
	hpa@...or.com
Subject: Re: [PATCH] irq: handle irq0 special only on x86

Hi David,

On Wed, Dec 09, 2009 at 01:41:51AM -0800, David Miller wrote:
> From: Américo Wang <xiyou.wangcong@...il.com>
> Date: Wed, 9 Dec 2009 17:28:09 +0800
> 
> > 2009/12/9 Uwe Kleine-König <u.kleine-koenig@...gutronix.de>:
> >> I just noticed this when digging in the irq handling. .,A At least for arm
> >> this doesn't make sense. .,A Not sure if x86 is the only arch this test
> >> is valid for, but probably it is.
> > 
> > No, it is not.
> > 
> > Try grep -Inr 'irq0' arch/*/kernel.
> 
> The edict was sent down long ago that IRQ number zero is
> special across the entire kernel tree.
This doesn't help here.  x86 uses irq0 for timing and AFAIK it's some
kind of catch-it-all interrupt---I don't know the exact details though.

> If IRQ zero can happen, you should offset the IRQ values you publish
> to the rest of the kernel, and translate them back when you process
> them internally.
Even if x86 will do that the problem remains.  After it does an offset
of 1 (say) the code will read as follows after adaption:

	/*
	 * But for 'irqfixup == 2' we also do it for handled interrupts if
	 * they are marked as IRQF_IRQPOLL (or for irq zero, which is the
	 * traditional PC timer interrupt.. Legacy)
	 */
	if (irqfixup < 2)
		return 0;

	if (irq == 1)
		return 1;

So try_misrouted_irq hard codes the value of the timer irq (be it zero
or one) and this is wrong for other archs like ARM where irq0 is used on
some machines, too.  There it's just an ordinary irq.

BTW I don't see a reason to forbid irq0 if you don't need to doubt of
it's validity even in driver code.

So if the resources of a platform device specify:

	struct resource mydevicesresources[] = {
		...
		{
			.start = 0,
			.end = 0,
			.flags = IORESOURCE_IRQ,
		},
		...
	};

I'd like to use the returned value by platform_get_irq for this device.

Note, I fully agree to use 0 for NO_IRQ if you have an int-sized value
that holds either NO_IRQ or a valid irq number.  But in practise I'd not
recommend to use this idiom.

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |
--
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/