linux-kernel - Re: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)

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: <4902135F.6080300@freescale.com>
Date:	Fri, 24 Oct 2008 13:26:39 -0500
From:	Scott Wood <scottwood@...escale.com>
To:	Chris Snook <csnook@...hat.com>
CC:	Kumar Gala <galak@...nel.crashing.org>,
	LinuxPPC-dev list <linuxppc-dev@...abs.org>,
	tglx@...utronix.de,
	linux-kernel Kernel <linux-kernel@...r.kernel.org>,
	maxk@...lcomm.com
Subject: Re: default IRQ affinity change in v2.6.27 (breaking several SMP
 PPC	based systems)

Chris Snook wrote:
> Scott Wood wrote:
>> Kumar Gala wrote:
>>> So why not just have x86 startup code set irq_default_affinity = 
>>> CPU_MASK_ALL than?
>>
>> That doesn't really solve the problem, as a user could still manually 
>> set an invalid affinity.  The MPIC driver should reduce the affinity 
>> itself to what the hardware can handle.
> 
> Does the MPIC code actually allow that to happen?

As far as I can tell, though I haven't tested it.

> I can't quite tell, but I noticed this:
> 
> [csnook@...noulli sysdev]$ fgrep '#ifdef CONFIG_' mpic.c | sort -u
> #ifdef CONFIG_IRQ_ALL_CPUS
> #ifdef CONFIG_MPIC_BROKEN_REGREAD
> #ifdef CONFIG_MPIC_U3_HT_IRQS
> #ifdef CONFIG_MPIC_WEIRD
> #ifdef CONFIG_PCI_MSI
> #ifdef CONFIG_PM
> #ifdef CONFIG_PPC32     /* XXX for now */
> #ifdef CONFIG_PPC_DCR
> #ifdef CONFIG_SMP
> 
> Do any of those config options (or combinations thereof) imply an MPIC 
> that can't handle an IRQ masked to multiple CPUs?  If so, this can be 
> fixed rather easily at build time, without having to muck around with 
> arch-specific initialization code.

I don't think so, and in any case it should be detected at runtime from 
the device tree.

-Scott

--
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/