| 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
| ||
|
Message-ID: <m1wrxzqarz.fsf@fess.ebiederm.org> Date: Sat, 27 Feb 2010 01:37:52 -0800 From: ebiederm@...ssion.com (Eric W. Biederman) To: Ingo Molnar <mingo@...e.hu> Cc: Yinghai Lu <yinghai@...nel.org>, mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org, tglx@...utronix.de, linux-tip-commits@...r.kernel.org Subject: Re: [tip:x86/irq] x86: apic: Fix mismerge, add arch_probe_nr_irqs() again Ingo Molnar <mingo@...e.hu> writes: > * Yinghai Lu <yinghai@...nel.org> wrote: > >> >> for x86, with radix tree based irq_to_desc(), >> removing arch_probe_nr_irqs is intentional. so we get more irq that could be used. >> >> wonder if the udev for some of your test system have irq number limitation? > > was ancient udev: udev-095-17.fc6. Something doesn't add up. Nowhere in the udev source is there a single mention of irq. gsi have fixed interrupt numbers so that would not change. The dynamic irqs are allocated starting from the high gsi and working up. The irq numbers that get allocated should not have changed, unless this was actually a bug fix in this configuration. The other possibility is that somehow arch_probe_nr_irqs() was returning a number greater than NR_IRQS. Ingo do you have any idea what NR_IRQS or nr_irqs were/are on that failing machine? Eric -- 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