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: <m18wc412ih.fsf@fess.ebiederm.org>
Date:	Mon, 11 Jan 2010 18:27:18 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Suresh Siddha <suresh.b.siddha@...el.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Yinghai Lu <yinghai@...nel.org>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch] x86, apic: use 0x20 for the IRQ_MOVE_CLEANUP_VECTOR instead of 0x1f

"H. Peter Anvin" <hpa@...or.com> writes:

> On 01/11/2010 05:52 PM, Eric W. Biederman wrote:
>> 
>> After having the documentation quoted at me.  I am having a distinct
>> memory of one piece of documentation saying:
>> "interrupts within a priority level can be delivered in any order"
>> 
>> So I am guessing there is not any ordering of interrupts in the same
>> priority level until they get to the local apic.
>> 
>
> There is no ordering of interrupts before they hit the local APIC, since
> the local APIC is what would serialize them...

The two wire bus that the all came across would serialize them.
I'm not certain how much of that was preserved with front-side
bus delivery.

>
>> What guarantee we need is the interesting question.
>> 
>> The cleanup ipi is sent when we have seen an interrupt arrive at it's
>> newly configured location.  It is possible that there is still an
>> interrupt in flight to the old configured location (think NUMA where
>> the interrupt has been migrated from off node to on node).  We want
>> the guarantee that the ipi arrives after the inflight irq.  Which
>> means on the wire ordering as well as in the local apic ordering is
>> interesting.
>
> I don't think there is any such guarantee possible, but that that has
> nothing to do with the interrupt priority.  Suresh tells me that that is
> handled by detecting and re-posting the migration IRQ.

The re-posting should only be for the case where we are migrating more
than one irq at a time.


>> I am slammed with other stuff right now so I don't think I will have
>> time to find the old documentation I was looking at for a couple of
>> more days.
>
> I'm wondering if what you're thinking of are the really old LAPICs which
> could only remember two pending interrupts per priority level?

Not precisely, but it could easily be something similar.


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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ