linux-kernel - Re: [PATCH] Fix compile failure on PA-RISC

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:	Thu, 10 May 2012 11:24:32 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Mikulas Patocka <mpatocka@...hat.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"James E.J. Bottomley" <jejb@...isc-linux.org>,
	Helge Deller <deller@....de>, linux-parisc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix compile failure on PA-RISC

On Wed, May 9, 2012 at 7:51 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, May 8, 2012 at 8:20 PM, Mikulas Patocka <mpatocka@...hat.com> wrote:
>>> Switching it to zero and testing that things still work would be appreciated.
>> It works, but there is plenty of interrupt controllers on PC-RISC and I
>> can only test it on C8000 with IO-SAPIC. I don't know if irq 0 is used on
>> some PA-RISC interrupt controller. It would be best if James Bottomley
>> tests it on his set of machines.
>
> Heh. It sounds like we have more PA-RISC machines than we have actual users.
>
>> And what about x86? --- irq 0 is used for timer and there is
>> void __init setup_default_timer_irq(void)
>> {
>>        setup_irq(0, &irq0);
>> }
>> in arch/x86/kernel/time.c.
>
> That's fine. There's no "irq" variable associated with it that people
> can test. No driver will ever see an irq number of zero, no dynamic
> irq code will ever see the zero.
>
> So x86 rules have always been that the way drivers etc test for irq
> existence has always been "irq 0 means no irq". Despite the fact that
> it internally uses irq0 for its own nefarious uses.

So can x86 please show the purely internal irq0 in its arch_show_interrupts(),
and accept "[PATCH] /proc/interrupts: irq zero is invalid"
(http://lkml.indiana.edu/hypermail/linux/kernel/1112.0/02229.html)?

Also, the several for_each_irq*() macros still iterate over zero, e.g.

# define for_each_irq_desc(irq, desc)                                   \
        for (irq = 0, desc = irq_to_desc(irq); irq < nr_irqs;           \
             irq++, desc = irq_to_desc(irq))                            \
                if (!desc)                                              \
                        ;                                               \
                else


# define for_each_irq_desc_reverse(irq, desc)                           \
        for (irq = nr_irqs - 1, desc = irq_to_desc(irq); irq >= 0;      \
             irq--, desc = irq_to_desc(irq))                            \
                if (!desc)                                              \
                        ;                                               \
                else

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/