linux-kernel - Re: [PATCH -rt] ide: fix interrupts processing issue with preempt-able 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]

Date:	Wed, 25 Jun 2008 16:34:31 +0400
From:	Anton Vorontsov <avorontsov@...mvista.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-ide@...r.kernel.org,
	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: [PATCH -rt] ide: fix interrupts processing issue with
	preempt-able hardirqs

On Tue, Jun 24, 2008 at 04:00:16AM +0400, Anton Vorontsov wrote:
> On Tue, Jun 24, 2008 at 01:51:41AM +0200, Ingo Molnar wrote:
> > 
> > * Anton Vorontsov <avorontsov@...mvista.com> wrote:
> > 
> > > IDE interrupt handler relies on the fact that, if necessary, hardirqs 
> > > will re-trigger on ISR exit. With fully preemtable IRQs this seems to 
> > > be not true, since if hardirq thread is currently running, and the 
> > > same IRQ raised again, then this IRQ will be simply lost.
> > 
> > actually no, that should not happen - if -rt loses an IRQ then something 
> > broke in the threaded IRQ code. It's supposed to be a drop-in, 
> > compatible IRQ flow with no driver changes needed.
> 
> ..just as I thought, the bug somewhere deeper... heh.

Ok, a bit more investigation showed that this is indeed not RT specific
per see, but issue emerges only on RT-style IRQ handlers + alim15x3 IDE
controller (for example, PDC20269 works ok).

The difference is that that with RT: low-level (non-threaded) IRQ
handler masks IDE IRQ, then wakes up appropriate IRQ thread, which calls
IDE handler, and then, after IDE handler exits, thread routine unmasks
IDE IRQ.

Without RT: low-level non-threaded IRQ handler does not mask specific
IRQ, but disables local interrupts, and calls IDE handler directly.

The bug, as I see it, in the alim15x3 (ULi M5228) hardware: for some
reason it does not hold IRQ line, but rises it for some short period
of time (while the drive itself rises and holds it correctly -- I'm
seeing it via oscilloscope).

So this scheme does not work:
mask_irq()
...do something that will trigger IDE interrupt...
unmask_irq()

Because at the unmask_irq() time IDE IRQ is gone already, and interrupt
controller could not notice it (interrupts are level sensitive).

I did following test: disable RT + insert mask/unmask sequence in the
IDE IRQ handler, and I got the same behaviour as with RT enabled.

Also, further testing showed that this issue isn't drive-specific, i.e.
with a delay inserted before the unmask_irq(), the bug shows with any
drive I have.

So, in summary: I think that the patch is still correct as a hw bug
workaround (I'll need to correct its comments and description though).

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