linux-kernel - RE: [PATCH v4] x86/irq: handle chained interrupts during IRQ migration

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] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1207120035080.32033@ionos>
Date:	Thu, 12 Jul 2012 00:56:50 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Iyer, Sundar" <sundar.iyer@...el.com>
cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
	"lethal@...ux-sh.org" <lethal@...ux-sh.org>,
	"Monroy, German" <german.monroy@...el.com>,
	Russell King <linux@....linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: RE: [PATCH v4] x86/irq: handle chained interrupts during IRQ
 migration

On Wed, 11 Jul 2012, Iyer, Sundar wrote:

> Hi Thomas,
> 
> Any status on this one?

Yes. I have thought about this some more.

1) Why is this an issue at all ?

   The irq is not visible to irqbalanced or /proc/irq/N/smp_affinity
   settings.

   So how would this irq have an affinity mask which is solely
   directed to a particular cpu which is going down?

   There is no documnted way to direct such an hidden irq to a
   particular cpu.

   I really can't find a reason for this. And without a reason that
   patch is completely pointless.

2) Why are chained handlers horrible on SMP?

   They are hidden from the system, so nothing can see them, assign
   affinities or such.

   That's a real drawback, as one might want to assign the demuxed
   irqs to CPUn, but the primary handler runs on some random other CPU
   and therefor the demuxed interrupts run in exaclty the context of
   the CPU which handles the primary interrupt.

   Granted that the chained handler setup spares a few CPU cycles, but
   at the same time it limits usability and debugabilty and causes
   such vehicles as the proposed patch.

What's the reason why you can't use a proper set up primary handler?

I can't see none, though I know that Russell will disagree :)

Thanks,

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