linux-kernel - Re: [PATCH 0/7] Boot IRQ quirks and rerouting

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:	Wed, 4 Jun 2008 19:33:35 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
cc:	Stefan Assmann <sassmann@...e.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Olaf Dabrunz <od@...e.de>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>,
	Jon Masters <jonathan@...masters.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] Boot IRQ quirks and rerouting

On Wed, 4 Jun 2008, Maciej W. Rozycki wrote:
> On Wed, 4 Jun 2008, Thomas Gleixner wrote:
> 
> > It does matter. When the interrupt is _not_ handled then it comes back
> > immediately for ever and after a while the kernel decides to disable
> > the legacy int, because nobody cares about the interrupt.
> 
>  Mental shortcut, sorry -- making the interrupt be discarded through the
> primary rather than the secondary, etc. I/O APIC does not change anything.  
> Based on the description of the problem, the interupt will just have to be
> delivered somewhere, so I see little purpose in complicating the routing
> and causing additional sharing just to discard the interrupt elsewhere
> anyway.  If INTx messages cannot be blocked on the way anywhere, then the 
> originating I/O APIC should never get its inputs masked and the handler 
> should take care of the unwanted interrupts there.  This is at least my 
> opinion.

There is no way to take care of an unwanted interrupt when there is no
handler which knows to deal with the device.

The problem case is mostly preempt-rt, where we receive the interrupt,
mask it and wake up the handler thread. We can not leave it unmasked
for obvious reasons.

>  BTW, it could be possible to mask the interrupt by fiddling with the
> vector used and the TPR instead -- we have a range of low-priority vectors
> which are never used for APIC interrupts, so the TPR may be hardcoded to
> some non-zero value for all systems and then for the problematic chipsets
> handlers may change vectors to mask or unmask APIC interrupts.  This would
> have to be verified on actual hardware and be conditional as it is likely
> to cause troubles for systems using serial interrupt delivery over the
> inter-APIC bus (the vector, delivery mode, etc. are generally not meant to
> be changed with the input unmasked for these chips -- which just shows how
> braindead the idea of the mask having side effects is).  Just a thought.

I tried this already and it results in extremly strange and randomly
changing behaviour up to a full system lockup :(

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/