linux-kernel - Re: [RT] MPIC edge sensitive issues with hardirq preemption (was: Re: [PATCH v2 -rt] ide: workaround buggy hardware issues with preemptable hardirqs)

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: <20080630223705.GA28503@polina.dev.rtsoft.ru>
Date:	Tue, 1 Jul 2008 02:37:05 +0400
From:	Anton Vorontsov <avorontsov@...mvista.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Sergei Shtylyov <sshtylyov@...mvista.com>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Daniel Walker <dwalker@...sta.com>
Subject: Re: [RT] MPIC edge sensitive issues with hardirq preemption (was:
	Re: [PATCH v2 -rt] ide: workaround buggy hardware issues with
	preemptable hardirqs)

On Tue, Jul 01, 2008 at 07:59:57AM +1000, Benjamin Herrenschmidt wrote:
> > 	
> > Thanks for the idea. With hardirq preempton, fasteoi path does not replay
> > edge interrupts indeed (at least for MPIC).
> > 
> > Here how I tested this: I have external interrupt connected to the button
> > on this board, thus I registered irq handler which is doing exactly this
> > (irq is edge sensitive):
> > 
> > printk("handled\n"); mdelay(2000);
> > 
> > Without hardirq preemption: pressing button twice prints two messages.
> > With hardirq preemption: pressing button twice prints just one message.
> > 
> > This happens because:
> > - irq has come;
> > - fasteoi handler mask()s it, and wakes up the thread;
> 
> Do we eoi first ? We should.

Yup. I just left over this small detail.

Without my patch the code was firstly masking the IRQ, then sending EOI.
Now we don't mask it, but simply send an EOI. If the edge IRQ came again
(while we were processing the same IRQ), non-threaded handler marks IRQ
that it should be replayed, then masks it and sends EOI. When thread
awakes, it unmasks the IRQ before handle_IRQ_event, so that we can catch
next edge IRQ. That is, we handle EOI quite correctly.

-- 
Anton Vorontsov
email: cbouatmailru@...il.com
irc://irc.freenode.net/bd2
--
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/