Komuro reports that ISA interrupts do not work after a disable_irq(),
causing some PCMCIA drivers to not work, with messages like

	eth0: Asix AX88190: io 0x300, irq 3, hw_addr xx:xx:xx:xx:xx:xx
	eth0: found link beat
	eth0: autonegotiation complete: 100baseT-FD selected
	eth0: interrupt(s) dropped!
	eth0: interrupt(s) dropped!
	eth0: interrupt(s) dropped!
	...

Linus Torvalds <torvalds@osdl.org> said:

  "Now, edge-triggered interrupts are a _lot_ harder to mask, because the
   Intel APIC is an unbelievable piece of sh*t, and has the edge-detect logic
   _before_ the mask logic, so if a edge happens _while_ the device is
   masked, you'll never ever see the edge ever again (unmasking will not
   cause a new edge, so you simply lost the interrupt).

   So when you "mask" an edge-triggered IRQ, you can't really mask it at all,
   because if you did that, you'd lose it forever if the IRQ comes in while
   you masked it. Instead, we're supposed to leave it active, and set a flag,
   and IF the IRQ comes in, we just remember it, and mask it at that point
   instead, and then on unmasking, we have to replay it by sending a
   self-IPI."

This trivial patch solves the problem.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@redhat.com>
Acked-by: NKomuro <komurojun-mbn@nifty.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This refactoring actually optimizes the code a little by caching the value
that we think the device is programmed with instead of reading it back from
the hardware.  Which simplifies the code a little and should speed things up a
bit.

This patch introduces the concept of a ht_irq_msg and modifies the
architecture read/write routines to update this code.

There is a minor consistency fix here as well as x86_64 forgot to initialize
the htirq as masked.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Andi Kleen <ak@suse.de>
Acked-by: NBryan O'Sullivan <bos@pathscale.com>
Cc: <olson@pathscale.com>
Cc: Roland Dreier <rolandd@cisco.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This is the x86-64 version of f9dadfa7
that did the same thing on i386.

Since the "mask" bit is in the low word, when we write a new entry, we
need to write the high word first, before we potentially unmask it.

The exception is when we actually want to mask the interrupt, in which
case we want to write the low word first to make sure that the high word
doesn't change while the interrupt routing is still active.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This is just commit 130fe05d ported to
x86-64, for all the same reasons.  It cleans up the IO-APIC accesses in
order to then fix the ordering issues.

We move the accessor functions (that were only used by io_apic.c) out of
a header file, and use proper memory-mapped accesses rather than making
up our own "volatile" pointers.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When I generalized __assign_irq_vector I failed to pay attention
to what happens when you access a per cpu data structure for
a cpu that is not online.   It is an undefined case making any
code that does it have undefined behavior as well.

The code still needs to be able to allocate a vector across cpus
that are not online to properly handle combinations like lowest
priority interrupt delivery and cpu_hotplug.  Not that we can do
that today but the infrastructure shouldn't prevent it.

So this patch updates the places where we touch per cpu data
to only touch online cpus, it makes cpu vector allocation
an atomic operation with respect to cpu hotplug, and it updates
the cpu start code to properly initialize vector_irq so we
don't have inconsistencies.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NAndi Kleen <ak@suse.de>

There is no reason to remember a per cpu position of which vector
to try.  Keeping a global position is simpler and more likely to
result in a global vector allocation even if I don't need or require
it.  For level triggered interrupts this means we are less likely to
acknowledge another cpus irq, and cause the level triggered irq to
harmlessly refire.

This simplification makes it easier to only access data structures
of  online cpus, by having fewer special cases to deal with.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NAndi Kleen <ak@suse.de>

By default route the 8254 over the 8259 and only disable
it on ATI boards where this causes double timer interrupts.

This should unbreak some Nvidia boards where the timer doesn't
seem to tick of it isn't enabled in the 8259. At least one
VIA board also seemed to have a little trouble with the disabled
8259.

For 2.6.20 we'll try both dynamically without black listing, but I think
for .19 this is the safer approach because it has been already well tested
in earlier kernels. This also makes the x86-64 behaviour the same
as i386.

Command line options can change all this of course.
Signed-off-by: NAndi Kleen <ak@suse.de>

Thanks to YH Lu for spotting this.  It appears I missed this function when I
refactored allocate_irq_vector and introduced irq_domain, with the result that
all retriggered irqs would go to cpu 0 even if we were not prepared to receive
them there.

While reviewing YH's patch I also noticed that this function was missing
locking, and since I am now reading two values from two diffrent arrays that
looks like a race we might be able to hit in the real world.

Cc: Yinghai Lu <yinghai.lu@amd.com>
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NAndi Kleen <ak@suse.de>

typo with cpu instead of new_cpu
Signed-off-by: NYinghai Lu <yinghai.lu@amd.com>
Signed-off-by: NAndi Kleen <ak@suse.de>

Introduce desc->name and eliminate the handle_irq_name() hack.  Add
set_irq_chip_and_handler_name() to set the flow type and name at once.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Matthew Wilcox <willy@debian.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch fixes my one line thinko where I was clearing
the vector_irq entries on the wrong cpus.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

hw_interrupt_type is deprecated in favour of struct irq_chip.

[mingo@elte.hu: do x86_64 too]
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The problem we can't take advantage of lowest priority delivery mode if
the vectors are allocated for only one cpu at a time.  Nor can we work
around hardware that assumes lowest priority delivery mode is always
used with several cpus.

So this patch introduces the concept of a vector_allocation_domain.  A
set of cpus that will receive an irq on the same vector.  Currently the
code for implementing this is placed in the genapic structure so we can
vary this depending on how we are using the io_apics.

This allows us to restore the previous behaviour of genapic_flat without
removing the benefits of having separate vector allocation for large
machines.

This should also fix the problem report where a hyperthreaded cpu was
receving the irq on the wrong hyperthread when in logical delivery mode
because the previous behaviour is restored.

This patch properly records our allocation of the first 16 irqs to the
first 16 available vectors on all cpus.  This should be fine but it may
run into problems with multiple interrupts at the same interrupt level.
Except for some badly maintained comments in the code and the behaviour
of the interrupt allocator I have no real understanding of that problem.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Acked-by: NMuli Ben-Yehuda <muli@il.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Which vector an irq is assigned to now varies dynamically and is
not needed outside of io_apic.c.  So remove the possibility
of accessing the information outside of io_apic.c and remove
the silly macro that makes looking for users of irq_vector
difficult.

The fact this compiles ensures there aren't any more pieces
of the old CONFIG_PCI_MSI weirdness that I failed to remove.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This moves the declarations for the architecture helpers into
include/linux/htirq.h from the generic include/linux/pci.h.  Hopefully this
will make this distinction clearer.

htirq.h is included where it is needed.

The dependency on the msi code is fixed and removed.

The Makefile is tidied up.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg KH <greg@kroah.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

It turns out msi_ops was simply not enough to abstract the architecture
specific details of msi.  So I have moved the resposibility of constructing
the struct irq_chip to the architectures, and have two architecture specific
functions arch_setup_msi_irq, and arch_teardown_msi_irq.

For simple architectures those functions can do all of the work.  For
architectures with platform dependencies they can call into the appropriate
platform code.

With this msi.c is finally free of assuming you have an apic, and this
actually takes less code.

The helpers for the architecture specific code are declared in the linux/msi.h
to keep them separate from the msi functions used by drivers in linux/pci.h
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg KH <greg@kroah.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch implements two functions ht_create_irq and ht_destroy_irq for
use by drivers.  Several other functions are implemented as helpers for
arch specific irq_chip handlers.

The driver for the card I tested this on isn't yet ready to be merged.
However this code is and hypertransport irqs are in use in a few other
places in the kernel.  Not that any of this will get merged before 2.6.19

Because the ipath-ht400 is slightly out of spec this code will need to be
generalized to work there.

I think all of the powerpc uses are for a plain interrupt controller in a
chipset so support for native hypertransport devices is a little less
interesting.

However I think this is a half way decent model on how to separate arch
specific and generic helper code, and I think this is a functional model of
how to get the architecture dependencies out of the msi code.

[akpm@osdl.org: Kconfig fix]
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Greg KH <greg@kroah.com>
Cc: Andi Kleen <ak@muc.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

With more irqs in the system we don't need this.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

After raising the number of irqs the system supports this function is no
longer necessary.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This refactors the irq handling code to make the vectors a per cpu resource so
the same vector number can be simultaneously used on multiple cpus for
different irqs.

This should make systems that were hitting limits on the total number of irqs
much more livable.

[akpm@osdl.org: build fix]
[akpm@osdl.org: __target_IO_APIC_irq is unneeded on UP]
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This is a small pessimization but it paves the way for making this information
per cpu.  Which allows the the maximum number of IRQS to become NR_CPUS*224.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch removes the change in behavior of the irq allocation code when
CONFIG_PCI_MSI is defined.  Removing all instances of the assumption that irq
== vector.

create_irq is rewritten to first allocate a free irq and then to assign that
irq a vector.

assign_irq_vector is made static and the AUTO_ASSIGN case which allocates an
vector not bound to an irq is removed.

The ioapic vector methods are removed, and everything now works with irqs.

The definition of NR_IRQS no longer depends on CONFIG_PCI_MSI
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This removes the hardcoded assumption that irq == vector in the msi
composition code, and it allows the msi message composition to setup logical
mode, or lowest priorirty delivery mode as we do for other apic interrupts,
and with the same selection criteria.

Basically this moves the problem of what is in the msi message into the
architecture irq management code where it belongs.  Not in a generic layer
that doesn't have enough information to compose msi messages properly.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The current implementation of create_irq() is a hack but it is the current
hack that msi.c uses, and unfortunately the ``generic'' apic msi ops depend on
this hack.  Thus we are this hack of assuming irq == vector until the
depencencies in the generic irq code are removed.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In the latest changes the code for migrating x86_64 irqs was dropped.  This
reads it in a fashion that will work even if we change the vector on level
triggered irqs when we migrate them.

[akpm@osdl.org: build fix]
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch converts all the x86_64 PIC controllers layers to the new and
simpler irq-chip interrupt handling layer.

[mingo@elte.hu: The patch also enables the fasteoi handler for x86_64]
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Roland Dreier <rolandd@cisco.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

ACPI went to great trouble to get the APIC version and CPU capabilities
of different CPUs before passing them to the mpparser. But all
that data was used was to print it out.  Actually it even faked some data
based on the boot cpu, not on the actual CPU being booted.

Remove all this code because it's not needed.

Cc: len.brown@intel.com
Signed-off-by: NAndi Kleen <ak@suse.de>

Instead of hackish manual parsing

Requires earlier i386 patchkit, but also fixes i386 early_printk again.

I removed some obsolete really early parameters which didn't do anything useful.
Also made a few parameters that needed it early (mostly oops printing setup)

Also removed one panic check that wasn't visible without
early console anyways (the early console is now initialized after that
panic)

This cleans up a lot of code.
Signed-off-by: NAndi Kleen <ak@suse.de>

Since we only support PCI and ISA legacy busses now there is no need to
have an full array with checking.
Signed-off-by: NAndi Kleen <ak@suse.de>

They did not really belong into io_apic.c. Move them into a new file
and clean it up a bit.

Also remove outdated ATI quirk that was obsolete,
Signed-off-by: NAndi Kleen <ak@suse.de>

The MPS table specification says that the operating system should
renumber the IO-APICs following the table as needed.  However in
ACPI this is not allowed or neeeded and all x86-64 systems are ACPI
compliant.

The code was already disabled on some systems because it caused
problems there. Remove it completely now.

CC: mdomsch@dell.com
Signed-off-by: NAndi Kleen <ak@suse.de>

The IO APIC code had lots of duplicated code to read/write 64bit
routing entries into the IO-APIC. Factor this out int common read/write
functions

In a few cases the IO APIC lock is taken more often now, but this
isn't a problem because it's all initialization/shutdown only
slow path code.
Signed-off-by: NAndi Kleen <ak@suse.de>

No 64bit EISA or Microchannel systems ever. Remove the left over code
in the IO-APIC driver and the mptable parser
Signed-off-by: NAndi Kleen <ak@suse.de>

This was an old workaround for broken MP-BIOS. The user could
specify overwrites on the command line.

I've never seen it being used for anything on 64bit. So get
rid of it for now.
Signed-off-by: NAndi Kleen <ak@suse.de>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Add ->retrigger() irq op to consolidate hw_irq_resend() implementations.
(Most architectures had it defined to NOP anyway.)

NOTE: ia64 needs testing. i386 and x86_64 tested.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch-queue improves the generic IRQ layer to be truly generic, by adding
various abstractions and features to it, without impacting existing
functionality.

While the queue can be best described as "fix and improve everything in the
generic IRQ layer that we could think of", and thus it consists of many
smaller features and lots of cleanups, the one feature that stands out most is
the new 'irq chip' abstraction.

The irq-chip abstraction is about describing and coding and IRQ controller
driver by mapping its raw hardware capabilities [and quirks, if needed] in a
straightforward way, without having to think about "IRQ flow"
(level/edge/etc.) type of details.

This stands in contrast with the current 'irq-type' model of genirq
architectures, which 'mixes' raw hardware capabilities with 'flow' details.
The patchset supports both types of irq controller designs at once, and
converts i386 and x86_64 to the new irq-chip design.

As a bonus side-effect of the irq-chip approach, chained interrupt controllers
(master/slave PIC constructs, etc.) are now supported by design as well.

The end result of this patchset intends to be simpler architecture-level code
and more consolidation between architectures.

We reused many bits of code and many concepts from Russell King's ARM IRQ
layer, the merging of which was one of the motivations for this patchset.

This patch:

rename desc->handler to desc->chip.

Originally i did not want to do this, because it's a big patch.  But having
both "desc->handler", "desc->handle_irq" and "action->handler" caused a
large degree of confusion and made the code appear alot less clean than it
truly is.

I have also attempted a dual approach as well by introducing a
desc->chip alias - but that just wasnt robust enough and broke
frequently.

So lets get over with this quickly.  The conversion was done automatically
via scripts and converts all the code in the kernel.

This renaming patch is the first one amongst the patches, so that the
remaining patches can stay flexible and can be merged and split up
without having some big monolithic patch act as a merge barrier.

[akpm@osdl.org: build fix]
[akpm@osdl.org: another build fix]
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

 - Rename the GART_IOMMU option to IOMMU to make clear it's not
   just for AMD
 - Rewrite the help text to better emphatise this fact
 - Make it an embedded option because too many people get it wrong.

To my astonishment I discovered the aacraid driver tests this
symbol directly. This looks quite broken to me - it's an internal
implementation detail of the PCI DMA API. Can the maintainer
please clarify what this test was intended to do?

Cc: linux-scsi@vger.kernel.org
Cc: alan@redhat.com
Cc: markh@osdl.org
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix a potential deadlock scenario introduced by io_apic.c's new vector_lock
on i386 and x86_64.

Found by the locking correctness validator. The patch was boot-tested on
x86. For details of the deadlock scenario, see the validator output:

  ======================================================
  [ BUG: hard-safe -> hard-unsafe lock order detected! ]
  ------------------------------------------------------
  idle/1 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
   (msi_lock){....}, at: [<c04ff8d2>] startup_msi_irq_wo_maskbit+0x10/0x35

  and this task is already holding:
   (&irq_desc[i].lock){++..}, at: [<c015b924>] probe_irq_on+0x36/0x107
  which would create a new lock dependency:
   (&irq_desc[i].lock){++..} -> (msi_lock){....}

  but this new dependency connects a hard-irq-safe lock:
   (&irq_desc[i].lock){++..}
  ... which became hard-irq-safe at:
    [<c01468c4>] lockdep_acquire+0x68/0x84
    [<c10485e9>] _spin_lock+0x21/0x2f
    [<c015aff5>] __do_IRQ+0x3d/0x113
    [<c01062d3>] do_IRQ+0x8c/0xad

  to a hard-irq-unsafe lock:
   (vector_lock){--..}
  ... which became hard-irq-unsafe at:
  ...  [<c01468c4>] lockdep_acquire+0x68/0x84
    [<c10485e9>] _spin_lock+0x21/0x2f
    [<c011b5e8>] assign_irq_vector+0x34/0xc8
    [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff
    [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa
    [<c010033f>] init+0x32/0x2cb
    [<c0102005>] kernel_thread_helper+0x5/0xb

  which could potentially lead to deadlocks!

  other info that might help us debug this:

  3 locks held by idle/1:
   #0:  (port_mutex){--..}, at: [<c067070d>] uart_add_one_port+0x61/0x289
   #1:  (&state->mutex){--..}, at: [<c067071f>] uart_add_one_port+0x73/0x289
   #2:  (&irq_desc[i].lock){++..}, at: [<c015b924>] probe_irq_on+0x36/0x107

  the hard-irq-safe lock's dependencies:
  -> (&irq_desc[i].lock){++..} ops: 9861 {
     initial-use  at:
                          [<c01468c4>] lockdep_acquire+0x68/0x84
                          [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                          [<c015b415>] setup_irq+0x9b/0x14d
                          [<c1aaa4c4>] time_init_hook+0xf/0x11
                          [<c1a9f320>] time_init+0x44/0x46
                          [<c1a9955f>] start_kernel+0x191/0x38f
                          [<c0100210>] 0xc0100210
     in-hardirq-W at:
                          [<c01468c4>] lockdep_acquire+0x68/0x84
                          [<c10485e9>] _spin_lock+0x21/0x2f
                          [<c015aff5>] __do_IRQ+0x3d/0x113
                          [<c01062d3>] do_IRQ+0x8c/0xad
     in-softirq-W at:
                          [<c01468c4>] lockdep_acquire+0x68/0x84
                          [<c10485e9>] _spin_lock+0x21/0x2f
                          [<c015aff5>] __do_IRQ+0x3d/0x113
                          [<c01062d3>] do_IRQ+0x8c/0xad
   }
   ... key      at: [<c1ea31e0>] irq_desc_lock_type+0x0/0x20
    -> (i8259A_lock){++..} ops: 5149 {
       initial-use  at:
                        [<c01468c4>] lockdep_acquire+0x68/0x84
                        [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                        [<c0108090>] init_8259A+0x11/0x8f
                        [<c1aa0d22>] init_ISA_irqs+0x12/0x4d
                        [<c1aaa4f0>] pre_intr_init_hook+0x8/0xa
                        [<c1aa0cb9>] init_IRQ+0xe/0x65
                        [<c1a99546>] start_kernel+0x178/0x38f
                        [<c0100210>] 0xc0100210
       in-hardirq-W at:
                        [<c01468c4>] lockdep_acquire+0x68/0x84
                        [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                        [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc
                        [<c015b007>] __do_IRQ+0x4f/0x113
                        [<c01062d3>] do_IRQ+0x8c/0xad
       in-softirq-W at:
                        [<c01468c4>] lockdep_acquire+0x68/0x84
                        [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                        [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc
                        [<c015b007>] __do_IRQ+0x4f/0x113
                        [<c01062d3>] do_IRQ+0x8c/0xad
     }
     ... key      at: [<c142f174>] i8259A_lock+0x14/0x40
   ... acquired at:
     [<c01468c4>] lockdep_acquire+0x68/0x84
     [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
     [<c0107eb2>] enable_8259A_irq+0x10/0x47
     [<c0107f12>] startup_8259A_irq+0x8/0xc
     [<c015b45e>] setup_irq+0xe4/0x14d
     [<c1aaa4c4>] time_init_hook+0xf/0x11
     [<c1a9f320>] time_init+0x44/0x46
     [<c1a9955f>] start_kernel+0x191/0x38f
     [<c0100210>] 0xc0100210

    -> (ioapic_lock){+...} ops: 122 {
       initial-use  at:
                        [<c01468c4>] lockdep_acquire+0x68/0x84
                        [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                        [<c1aa71db>] io_apic_get_version+0x16/0x55
                        [<c1aa5c73>] mp_register_ioapic+0xc6/0x127
                        [<c1aa382e>] acpi_parse_ioapic+0x2d/0x39
                        [<c1abe031>] acpi_table_parse_madt_family+0xb4/0x100
                        [<c1abe093>] acpi_table_parse_madt+0x16/0x18
                        [<c1aa3c8a>] acpi_boot_init+0x132/0x251
                        [<c1aa08ea>] setup_arch+0xd36/0xe37
                        [<c1a99434>] start_kernel+0x66/0x38f
                        [<c0100210>] 0xc0100210
       in-hardirq-W at:
                        [<c01468c4>] lockdep_acquire+0x68/0x84
                        [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                        [<c011bce1>] mask_IO_APIC_irq+0x11/0x31
                        [<c011c5cc>] ack_edge_ioapic_vector+0x31/0x41
                        [<c015b007>] __do_IRQ+0x4f/0x113
                        [<c01062d3>] do_IRQ+0x8c/0xad
     }
     ... key      at: [<c1432514>] ioapic_lock+0x14/0x3c
      -> (i8259A_lock){++..} ops: 5149 {
         initial-use  at:
                         [<c01468c4>] lockdep_acquire+0x68/0x84
                         [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                         [<c0108090>] init_8259A+0x11/0x8f
                         [<c1aa0d22>] init_ISA_irqs+0x12/0x4d
                         [<c1aaa4f0>] pre_intr_init_hook+0x8/0xa
                         [<c1aa0cb9>] init_IRQ+0xe/0x65
                         [<c1a99546>] start_kernel+0x178/0x38f
                         [<c0100210>] 0xc0100210
         in-hardirq-W at:
                         [<c01468c4>] lockdep_acquire+0x68/0x84
                         [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                         [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc
                         [<c015b007>] __do_IRQ+0x4f/0x113
                         [<c01062d3>] do_IRQ+0x8c/0xad
         in-softirq-W at:
                         [<c01468c4>] lockdep_acquire+0x68/0x84
                         [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
                         [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc
                         [<c015b007>] __do_IRQ+0x4f/0x113
                         [<c01062d3>] do_IRQ+0x8c/0xad
       }
       ... key      at: [<c142f174>] i8259A_lock+0x14/0x40
     ... acquired at:
     [<c01468c4>] lockdep_acquire+0x68/0x84
     [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
     [<c0107e6b>] disable_8259A_irq+0x10/0x47
     [<c011bdbd>] startup_edge_ioapic_vector+0x31/0x58
     [<c015b45e>] setup_irq+0xe4/0x14d
     [<c015b5a1>] request_irq+0xda/0xf9
     [<c1ac983a>] rtc_init+0x6a/0x1a7
     [<c0100457>] init+0x14a/0x2cb
     [<c0102005>] kernel_thread_helper+0x5/0xb

   ... acquired at:
     [<c01468c4>] lockdep_acquire+0x68/0x84
     [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
     [<c011bce1>] mask_IO_APIC_irq+0x11/0x31
     [<c011c5cc>] ack_edge_ioapic_vector+0x31/0x41
     [<c015b007>] __do_IRQ+0x4f/0x113
     [<c01062d3>] do_IRQ+0x8c/0xad

  the hard-irq-unsafe lock's dependencies:
  -> (vector_lock){--..} ops: 31 {
     initial-use  at:
                          [<c01468c4>] lockdep_acquire+0x68/0x84
                          [<c10485e9>] _spin_lock+0x21/0x2f
                          [<c011b5e8>] assign_irq_vector+0x34/0xc8
                          [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff
                          [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa
                          [<c010033f>] init+0x32/0x2cb
                          [<c0102005>] kernel_thread_helper+0x5/0xb
     softirq-on-W at:
                          [<c01468c4>] lockdep_acquire+0x68/0x84
                          [<c10485e9>] _spin_lock+0x21/0x2f
                          [<c011b5e8>] assign_irq_vector+0x34/0xc8
                          [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff
                          [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa
                          [<c010033f>] init+0x32/0x2cb
                          [<c0102005>] kernel_thread_helper+0x5/0xb
     hardirq-on-W at:
                          [<c01468c4>] lockdep_acquire+0x68/0x84
                          [<c10485e9>] _spin_lock+0x21/0x2f
                          [<c011b5e8>] assign_irq_vector+0x34/0xc8
                          [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff
                          [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa
                          [<c010033f>] init+0x32/0x2cb
                          [<c0102005>] kernel_thread_helper+0x5/0xb
   }
   ... key      at: [<c1432574>] vector_lock+0x14/0x3c

  stack backtrace:
   [<c0104f36>] show_trace+0xd/0xf
   [<c010543e>] dump_stack+0x17/0x19
   [<c0144e34>] check_usage+0x1f6/0x203
   [<c0146395>] __lockdep_acquire+0x8c2/0xaa5
   [<c01468c4>] lockdep_acquire+0x68/0x84
   [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a
   [<c04ff8d2>] startup_msi_irq_wo_maskbit+0x10/0x35
   [<c015b932>] probe_irq_on+0x44/0x107
   [<c0673d58>] serial8250_config_port+0x84b/0x986
   [<c06707b1>] uart_add_one_port+0x105/0x289
   [<c1ace54b>] serial8250_init+0xc3/0x10a
   [<c0100457>] init+0x14a/0x2cb
   [<c0102005>] kernel_thread_helper+0x5/0xb
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Cc: Jan Beulich <jbeulich@novell.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>