76ba59f836
Calling irq_find_mapping from outside a irq_{enter,exit} section is
unsafe and produces ugly messages if CONFIG_PROVE_RCU is enabled:
If coming from the idle state, the rcu_read_lock call in irq_find_mapping
will generate an unpleasant warning:
<quote>
===============================
[ INFO: suspicious RCU usage. ]
3.16.0-rc1+ #135 Not tainted
-------------------------------
include/linux/rcupdate.h:871 rcu_read_lock() used illegally while idle!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
#0: (rcu_read_lock){......}, at: [<ffffffc00010206c>]
irq_find_mapping+0x4c/0x198
</quote>
As this issue is fairly widespread and involves at least three
different architectures, a possible solution is to add a new
handle_domain_irq entry point into the generic IRQ code that
the interrupt controller code can call.
This new function takes an irq_domain, and calls into irq_find_domain
inside the irq_{enter,exit} block. An additional "lookup" parameter is
used to allow non-domain architecture code to be replaced by this as well.
Interrupt controllers can then be updated to use the new mechanism.
This code is sitting behind a new CONFIG_HANDLE_DOMAIN_IRQ, as not all
architectures implement set_irq_regs (yes, mn10300, I'm looking at you...).
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1409047421-27649-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
88 lines
2.2 KiB
Text
88 lines
2.2 KiB
Text
menu "IRQ subsystem"
|
|
# Options selectable by the architecture code
|
|
|
|
# Make sparse irq Kconfig switch below available
|
|
config MAY_HAVE_SPARSE_IRQ
|
|
bool
|
|
|
|
# Legacy support, required for itanic
|
|
config GENERIC_IRQ_LEGACY
|
|
bool
|
|
|
|
# Enable the generic irq autoprobe mechanism
|
|
config GENERIC_IRQ_PROBE
|
|
bool
|
|
|
|
# Use the generic /proc/interrupts implementation
|
|
config GENERIC_IRQ_SHOW
|
|
bool
|
|
|
|
# Print level/edge extra information
|
|
config GENERIC_IRQ_SHOW_LEVEL
|
|
bool
|
|
|
|
# Facility to allocate a hardware interrupt. This is legacy support
|
|
# and should not be used in new code. Use irq domains instead.
|
|
config GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
|
|
bool
|
|
|
|
# Support for delayed migration from interrupt context
|
|
config GENERIC_PENDING_IRQ
|
|
bool
|
|
|
|
# Alpha specific irq affinity mechanism
|
|
config AUTO_IRQ_AFFINITY
|
|
bool
|
|
|
|
# Tasklet based software resend for pending interrupts on enable_irq()
|
|
config HARDIRQS_SW_RESEND
|
|
bool
|
|
|
|
# Preflow handler support for fasteoi (sparc64)
|
|
config IRQ_PREFLOW_FASTEOI
|
|
bool
|
|
|
|
# Edge style eoi based handler (cell)
|
|
config IRQ_EDGE_EOI_HANDLER
|
|
bool
|
|
|
|
# Generic configurable interrupt chip implementation
|
|
config GENERIC_IRQ_CHIP
|
|
bool
|
|
select IRQ_DOMAIN
|
|
|
|
# Generic irq_domain hw <--> linux irq number translation
|
|
config IRQ_DOMAIN
|
|
bool
|
|
|
|
config HANDLE_DOMAIN_IRQ
|
|
bool
|
|
|
|
config IRQ_DOMAIN_DEBUG
|
|
bool "Expose hardware/virtual IRQ mapping via debugfs"
|
|
depends on IRQ_DOMAIN && DEBUG_FS
|
|
help
|
|
This option will show the mapping relationship between hardware irq
|
|
numbers and Linux irq numbers. The mapping is exposed via debugfs
|
|
in the file "irq_domain_mapping".
|
|
|
|
If you don't know what this means you don't need it.
|
|
|
|
# Support forced irq threading
|
|
config IRQ_FORCED_THREADING
|
|
bool
|
|
|
|
config SPARSE_IRQ
|
|
bool "Support sparse irq numbering" if MAY_HAVE_SPARSE_IRQ
|
|
---help---
|
|
|
|
Sparse irq numbering is useful for distro kernels that want
|
|
to define a high CONFIG_NR_CPUS value but still want to have
|
|
low kernel memory footprint on smaller machines.
|
|
|
|
( Sparse irqs can also be beneficial on NUMA boxes, as they spread
|
|
out the interrupt descriptors in a more NUMA-friendly way. )
|
|
|
|
If you don't know what to do here, say N.
|
|
|
|
endmenu
|