linux-kernel - RE: [BUG][RFC][GENERIC IRQ] linux-2.6.24 (delayed) disable IRQ feature not functional for handle_simple

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: <600D5CB4DFD93545BF61FF01473D11AC12622A36@limkexm2.ad.analog.com>
Date:	Tue, 19 Feb 2008 11:51:21 -0000
From:	"Hennerich, Michael" <Michael.Hennerich@...log.com>
To:	"Thomas Gleixner" <tglx@...utronix.de>,
	"Hennerich, Michael" <Michael.Hennerich@...log.com>
Cc:	<mingo@...e.hu>, <linux-kernel@...r.kernel.org>
Subject: RE: [BUG][RFC][GENERIC IRQ] linux-2.6.24 (delayed) disable IRQ feature not functional for handle_simple_irq


>From: Thomas Gleixner, Dienstag, 19. Februar 2008 11:49
>Subject: Re: [BUG][RFC][GENERIC IRQ] linux-2.6.24 (delayed) disable IRQ
>feature not functional for handle_simple_irq
>
>On Tue, 19 Feb 2008, Hennerich, Michael wrote:
>> Thomas,
>>
>> I have reasonable doubt that the delayed disable feature on
>> linux-2.6.24 for handle_simple_irq is broken.
>>
>> In 2.6.22 there was something like this:
>>
>> 	if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
>> 		if (desc->chip->mask)
>> 			desc->chip->mask(irq);
>> ...
>>
>> However in 2.6.24 the "DISABLED" IRQ in case it happens is never
going to
>be masked.
>>
>> 	if (unlikely(!action || (desc->status & IRQ_DISABLED)))
>> 		goto out_unlock;
>>
>>
>> I see a disabled IRQ being invoked in an endless loop.
>
>Simple irq's are special, see the comment above handle_simple_irq:
>
>Simple interrupts are either sent from a demultiplexing interrupt
>handler or come from hardware, where no interrupt hardware control
>is necessary.
>
>Note: The caller is expected to handle the ack, clear, mask and
>unmask issues if necessary.
>
>Simple irqs are used for low level demultiplex handlers, where the full
>control of the irqchip is in the low level handler.
>
>See also the commit log of 971e5b35fb02c5088d49e6c024aab73582a35b71
>
>    In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq
disabling
>    was implemented, and the simple irq handler had a masking set to
it.
>
>    Remy Bohmer discovered that some devices in the ARM architecture
>    would trigger the mask, but never unmask it. His patch to do the
>    unmasking was questioned by Russell King about masking simple irqs
>    to begin with. Looking further, it was discovered that the problems
>    Remy was seeing was due to improper use of the simple handler by
>    devices, and he later submitted patches to fix those. But the issue
>    that was uncovered was that the simple handler should never mask.
>
>    This patch reverts the masking in the simple handler.
>
>Thanks,
>
>	tglx


Ok - I see no problem that the simple handler doesn't mask the IRQ by
default like the level irq handler does.

However if I use disable_irq(irq) I would expect that the irq is somehow
disabled afterwards.

Our internal system IRQs doesn't need to be acked on the System
Interrupt Controller Level and we have simply just mask and unmask.


So I think I have two alternatives.

1) Bypass the delayed disable feature by implementing chip->disable and
chip->enable (simply map to mask and unmask)

2) Use level irq

Best regards,
Michael 
--
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/