linux-kernel - Re: kernel BUG at arch/x86/kernel/io_apic

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: <m1fxps17bu.fsf@frodo.ebiederm.org>
Date:	Tue, 29 Jul 2008 18:36:37 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Mike Travis <travis@....com>, Yinghai Lu <yhlu.kernel@...il.com>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	lkml <linux-kernel@...r.kernel.org>,
	Jack Steiner <steiner@....com>, Alan Mayer <ajm@....com>,
	Cliff Wickman <cpw@....com>
Subject: Re: kernel BUG at arch/x86/kernel/io_apic_64.c:357!

Jeremy Fitzhardinge <jeremy@...p.org> writes:

>> Generally easy except for the disparate methods of catching interrupts.
>>
>
> Catching in what sense?  I assume the interrupt gets raised in some
> source-specific way, and then passed into a generic layer where it eventually
> gets matched with an appropriate handler.  I'm sure there's some subtlety I'm
> missing.

Sorry.  Probably too much context in my head.
The model I use is irq sources throw interrupts and then the cpus catch them.
Sometimes those in flight irqs go through several transformations.

Given that the event channels that logical irq are bound to change over time
I would say they appear to be not irq sources.  Those are the physical
lines coming out of hardware devices (if physical), and the equivalent
parts of the hardware when the irqs are sent message based.

So it does sound like the event channels function much like vectors.  Which
are the token thrown from ioapics to cpus to tell them which irq has happened
but have nothing to do with it.

The sources and the linux irq numbers should be stable if you don't unplug
anything.  The rest are implementation details the architecture should hide.

In that case I don't see any reason we could not be receiving irqs with the
cpus catching vectors and with events showing up in event channels.  Having
both running at the same time is a little odd but doable.

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/