linux-kernel - Re: [PATCH] x86: Document the hotplug code is incompatible with x86 irq handling

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:	Tue, 12 Jun 2007 14:56:59 -0700
From:	"Siddha, Suresh B" <suresh.b.siddha@...el.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Pavel Machek <pavel@....cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...e.de>, linux-kernel@...r.kernel.org,
	Neil Brown <neilb@...e.de>, Ingo Molnar <mingo@...e.hu>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	asit.k.mallick@...el.com
Subject: Re: [PATCH] x86: Document the hotplug code is incompatible with x86 irq handling

On Tue, Jun 12, 2007 at 10:52:09PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, 12 June 2007 20:19, Eric W. Biederman wrote:
> > Because you are calling unfixably broken code.  That should be a decent
> > incentive to do something else won't it?
> 
> Can you please tell me _what_ else can be done?
> 
> > IOAPICs do not support what the code is doing here.  There is lots of
> > practical evidence including bad experiences and practical tests that
> > support this.
> 
> Well, AFAICS, Suresh has tried to debug one failing case recently without
> any consistent conclusions.  I don't know of any other test cases (links,
> please?).

Rafael, Darrick Wong's issue looks different and hence I was motivated to
look and fix if it was a SW issue. For now, I am not able to comprehend
what is happening on Darrick Wong's system. Need more help from Darrick
as he has the golden failing system.

Meanwhile I talked to our hardware folks about the irq migration in general.

One good news is that future versions of chipsets will have an Interrupt
Remapping feature(for more details please refer to
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf)
where in we can reliably migrate the irq to someother cpu in the process
context.

And for the existing platforms, chipset folks don't see a reason why the
Eric's algorithm(specified below) should fail.

Eric's algorithm for level triggered(edge triggered should be easier than
level triggered):
- Mask the irq in process context.
- Poll RIRR until an ack of for the irq was not pending.
- Migrate the irq.

Eric had a problem of stuck remote IRR on E75xx chipset with this algorithm
and my next step is to reproduce this issue on this platform and understand
the behavior.

thanks,
suresh
-
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/