linux-kernel - Re: [patch 00/26] x64, x2apic/intr-remap: Interrupt-remapping and x2apic support

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: <m1prplv71d.fsf@frodo.ebiederm.org>
Date:	Thu, 10 Jul 2008 13:05:50 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Suresh Siddha <suresh.b.siddha@...el.com>
Cc:	mingo@...e.hu, hpa@...or.com, tglx@...utronix.de,
	akpm@...ux-foundation.org, arjan@...ux.intel.com,
	andi@...stfloor.org, jbarnes@...tuousgeek.org, steiner@....com,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 00/26] x64, x2apic/intr-remap: Interrupt-remapping and x2apic support

At a quick skim nothing looks really bad, nothing looks really bad,
but you are dealing in an area of code that could be made much nicer
and if we are going to support a noticeably different style of irq
management we need to get in some of those pending cleanups so the
code does not fall down under it's own wait.

Suresh Siddha <suresh.b.siddha@...el.com> writes:

> irq migration in the presence of interrupt-remapping is done from the
> process-context as opposed to interrupt-context. Interrupt-remapping
> infrastrucutre allows us to do this migration in a simple fashion (atleast for
> edge triggered interrupts).

Unless I have misread things this irq migration remains racy, as I did not
see any instructions that would guarantee that in flight irqs were flushed
to the cpus local apics before we cleaned up the destination.

You are sizing an array as NR_IRQS this is something there should be sufficient
existing infrastructure to avoid.  Arrays sized by NR_IRQS is a significant
problem both for scaling the system up and down so ultimately we need to kill
this.  For now we should not introduce any new arrays.

A lot of your code is generic, and some of it is for just x86_64.  Since the
cpus are capable of running in 32bit mode.  We really need to implement x86_32
and x86_64 support in the same code base.  Which I believe means factoring out
pieces of io_apic_N.c into things such as msi.c that can be shared between the
two architectures.

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/