linux-kernel - Re: What are the real ioapic rte programming constraints?

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

Date:	Sun, 11 Feb 2007 14:36:47 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Natalie Protasevich" <protasnb@...il.com>
Cc:	"Zwane Mwaikambo" <zwane@...radead.org>,
	"Ashok Raj" <ashok.raj@...el.com>, "Ingo Molnar" <mingo@...e.hu>,
	"Andrew Morton" <akpm@...l.org>, linux-kernel@...r.kernel.org,
	"Lu, Yinghai" <yinghai.lu@....com>, "Andi Kleen" <ak@...e.de>,
	"Coywolf Qi Hunt" <coywolf@...ecn.org>
Subject: Re: What are the real ioapic rte programming constraints?

"Natalie Protasevich" <protasnb@...il.com> writes:

> On 2/11/07, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
>     The code currently in the kernel does:
>
>     pending
>     mask
>     read io_apic
>     ack
>     reprogram vector and destination
>     unmask
>
>     So I guess it does retain the bug fix.
>
>     What I am looking at doing is:
>
>     mask
>     read io_apic
>     -- Past this point no more irqs are expected from the io_apic
>     -- Now I work to drain any inflight/pending instances of the irq
>     send ipi to all irq destinations cpus and wait for it to return
>     read lapic
>     disable local irqs
>     take irq lock
>     -- Now no more irqs are expected to arrive
>     reprogram vector and destination
>     enable local irqs
>     unmask
>
>     What I need to ensure is that I have a point where I will not receive any
>     new messages from an ioapic about a particular irq anymore.  Even if
>     everything is working perfectly setting the disable bit is not enough
>     because there could be an irq message in flight. So I need to give any
>     in flight irqs a chance to complete.
>
>
> It is probably safer to have "interlapping" time in having second rte
> programmed, then both willl have the same vector and receive the eoi. And if
> you have interrupts disabled for a little while before you dismantle the old
> entry it should insure that all the in-flight ones got services and acked...
> --Natalie

I am assuming you mean interrupts disabled at the ioapic.  If that
is true mostly I agree with your assertion.

If you look above the mask is where I disable that interrupt source on
the ioapic.  I then send an ipi to all of the other possible cpus and
read the local apic to ensure that the window is over in which I need
to handle interrupts at the old destination. 

If I don't know when the window ends I can never dismantle the data
structures for receiving the irq at the old destination.  Ouch!

If I know how long I have to wait until I can clean up the data
structure at the old destination I don't have to worry about
overlapping interrupts.

Therefore it doesn't by me anything but complexity to setup the data
structures on the new cpu before the window for receiving the irqs
has completed.

Make sense?

Eric



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