* [PATCH] irq: sparse irqs, fix
2008-08-14 13:26 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Ingo Molnar
@ 2008-08-14 13:31 ` Ingo Molnar
2008-08-14 13:36 ` [PATCH] irq: sparse irqs, fix #2 Ingo Molnar
` (5 subsequent siblings)
6 siblings, 0 replies; 25+ messages in thread
From: Ingo Molnar @ 2008-08-14 13:31 UTC (permalink / raw)
To: Yinghai Lu
Cc: Thomas Gleixner, H. Peter Anvin, linux-kernel, Alan Cox,
Eric W. Biederman, Andrew Morton
>From 547c9dd238f4412622fb6a2622d81c35c0a9fb85 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 14 Aug 2008 15:32:59 +0200
Subject: [PATCH] irq: sparse irqs, fix
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
fix:
drivers/pci/intel-iommu.c: In function ‘dmar_set_interrupt':
drivers/pci/intel-iommu.c:918: error: too few arguments to function ‘create_irq'
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
drivers/pci/intel-iommu.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 389fdd6..be10d86 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -915,7 +915,7 @@ int dmar_set_interrupt(struct intel_iommu *iommu)
{
int irq, ret;
- irq = create_irq();
+ irq = create_irq(0);
if (!irq) {
printk(KERN_ERR "IOMMU: no free vectors\n");
return -EINVAL;
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH] irq: sparse irqs, fix #2
2008-08-14 13:26 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Ingo Molnar
2008-08-14 13:31 ` [PATCH] irq: sparse irqs, fix Ingo Molnar
@ 2008-08-14 13:36 ` Ingo Molnar
2008-08-14 16:33 ` Andrew Morton
2008-08-14 13:53 ` [PATCH] irq: sparse irqs, fix IRQ auto-probe crash Ingo Molnar
` (4 subsequent siblings)
6 siblings, 1 reply; 25+ messages in thread
From: Ingo Molnar @ 2008-08-14 13:36 UTC (permalink / raw)
To: Yinghai Lu
Cc: Thomas Gleixner, H. Peter Anvin, linux-kernel, Alan Cox,
Eric W. Biederman, Andrew Morton
>From 28f153577fc82ff93cd63472134b40f0634bff70 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 14 Aug 2008 15:38:50 +0200
Subject: [PATCH] irq: sparse irqs, fix #2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
fix:
In file included from arch/x86/kernel/setup.c:99:
include/asm-x86/mach-default/mach_apic.h:142: error: expected ‘)’ before ‘->’ token
That hunk got mis-merged.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
include/asm-x86/mach-default/mach_apic.h | 27 ++++++++++++++-------------
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/include/asm-x86/mach-default/mach_apic.h b/include/asm-x86/mach-default/mach_apic.h
index a4a8f92..ea04182 100644
--- a/include/asm-x86/mach-default/mach_apic.h
+++ b/include/asm-x86/mach-default/mach_apic.h
@@ -85,6 +85,20 @@ static inline int apicid_to_node(int logical_apicid)
return 0;
#endif
}
+
+static inline cpumask_t vector_allocation_domain(int cpu)
+{
+ /* Careful. Some cpus do not strictly honor the set of cpus
+ * specified in the interrupt destination when using lowest
+ * priority interrupt delivery mode.
+ *
+ * In particular there was a hyperthreading cpu observed to
+ * deliver interrupts to the wrong hyperthread when only one
+ * hyperthread was specified in the interrupt desitination.
+ */
+ cpumask_t domain = { { [0] = APIC_ALL_CPUS, } };
+ return domain;
+}
#endif
static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
@@ -139,18 +153,5 @@ static inline void enable_apic_mode(void)
{
}
-static inline cpumask_t vector_allocation_domain(int cpu)
-{
- /* Careful. Some cpus do not strictly honor the set of cpus
- * specified in the interrupt destination when using lowest
- * priority interrupt delivery mode.
- *
- * In particular there was a hyperthreading cpu observed to
- * deliver interrupts to the wrong hyperthread when only one
- * hyperthread was specified in the interrupt desitination.
- */
- cpumask_t domain = { { [0] = APIC_ALL_CPUS, } };
- return domain;
-}
#endif /* CONFIG_X86_LOCAL_APIC */
#endif /* ASM_X86__MACH_DEFAULT__MACH_APIC_H */
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH] irq: sparse irqs, fix #2
2008-08-14 13:36 ` [PATCH] irq: sparse irqs, fix #2 Ingo Molnar
@ 2008-08-14 16:33 ` Andrew Morton
2008-08-14 17:03 ` Eric W. Biederman
0 siblings, 1 reply; 25+ messages in thread
From: Andrew Morton @ 2008-08-14 16:33 UTC (permalink / raw)
To: Ingo Molnar
Cc: Yinghai Lu, Thomas Gleixner, H. Peter Anvin, linux-kernel,
Alan Cox, Eric W. Biederman
On Thu, 14 Aug 2008 15:36:52 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> +static inline cpumask_t vector_allocation_domain(int cpu)
> +{
> + /* Careful. Some cpus do not strictly honor the set of cpus
> + * specified in the interrupt destination when using lowest
> + * priority interrupt delivery mode.
> + *
> + * In particular there was a hyperthreading cpu observed to
> + * deliver interrupts to the wrong hyperthread when only one
> + * hyperthread was specified in the interrupt desitination.
> + */
> + cpumask_t domain = { { [0] = APIC_ALL_CPUS, } };
> + return domain;
> +}
I haven't looked at callers of this, but...
Does it need to be allocated on the stack? Local cpumask_t's are a
size problem. Can we build this in .rodata at compile time instead?
Is this the caller?
+ for_each_cpu_mask(cpu, mask) {
+ cpumask_t domain, new_mask;
+ int new_cpu;
+ int vector;
+
+ domain = vector_allocation_domain(cpu);
+ cpus_and(new_mask, domain, cpu_online_map);
If so we could perhaps do
static noinline const cpumask_t *vector_allocation_domain(int cpu)
{
/* Careful. Some cpus do not strictly honor the set of cpus
* specified in the interrupt destination when using lowest
* priority interrupt delivery mode.
*
* In particular there was a hyperthreading cpu observed to
* deliver interrupts to the wrong hyperthread when only one
* hyperthread was specified in the interrupt desitination.
*/
static const cpumask_t domain = { { [0] = APIC_ALL_CPUS, } };
return &domain;
}
...
+ for_each_cpu_mask(cpu, mask) {
+ cpumask_t domain, new_mask;
+ int new_cpu;
+ int vector;
+
+ __cpus_and(new_mask, vector_allocation_domain(cpu),
+ &cpu_online_map);
otoh, perhaps this new function is one implementation of
genapic.vector_allocation_domain(), in which case the inlining was
unneeded and misleading.
I give up. Have a little think about the stack bloat, please.
btw, whoever wrote that function is in need of a tab key.
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH] irq: sparse irqs, fix #2
2008-08-14 16:33 ` Andrew Morton
@ 2008-08-14 17:03 ` Eric W. Biederman
0 siblings, 0 replies; 25+ messages in thread
From: Eric W. Biederman @ 2008-08-14 17:03 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, Yinghai Lu, Thomas Gleixner, H. Peter Anvin,
linux-kernel, Alan Cox
Andrew Morton <akpm@linux-foundation.org> writes:
> On Thu, 14 Aug 2008 15:36:52 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
>> +static inline cpumask_t vector_allocation_domain(int cpu)
>> +{
>> + /* Careful. Some cpus do not strictly honor the set of cpus
>> + * specified in the interrupt destination when using lowest
>> + * priority interrupt delivery mode.
>> + *
>> + * In particular there was a hyperthreading cpu observed to
>> + * deliver interrupts to the wrong hyperthread when only one
>> + * hyperthread was specified in the interrupt desitination.
>> + */
>> + cpumask_t domain = { { [0] = APIC_ALL_CPUS, } };
>> + return domain;
>> +}
>
> I haven't looked at callers of this, but...
>
> Does it need to be allocated on the stack? Local cpumask_t's are a
> size problem. Can we build this in .rodata at compile time instead?
>
> Is this the caller?
Yes.
>
> + for_each_cpu_mask(cpu, mask) {
> + cpumask_t domain, new_mask;
> + int new_cpu;
> + int vector;
> +
> + domain = vector_allocation_domain(cpu);
> + cpus_and(new_mask, domain, cpu_online_map);
>
> If so we could perhaps do
>
>
> static noinline const cpumask_t *vector_allocation_domain(int cpu)
> {
> /* Careful. Some cpus do not strictly honor the set of cpus
> * specified in the interrupt destination when using lowest
> * priority interrupt delivery mode.
> *
> * In particular there was a hyperthreading cpu observed to
> * deliver interrupts to the wrong hyperthread when only one
> * hyperthread was specified in the interrupt desitination.
> */
> static const cpumask_t domain = { { [0] = APIC_ALL_CPUS, } };
> return &domain;
> }
>
>
> ...
>
> + for_each_cpu_mask(cpu, mask) {
> + cpumask_t domain, new_mask;
> + int new_cpu;
> + int vector;
> +
> + __cpus_and(new_mask, vector_allocation_domain(cpu),
> + &cpu_online_map);
>
> otoh, perhaps this new function is one implementation of
> genapic.vector_allocation_domain(), in which case the inlining was
> unneeded and misleading.
Likely. Why these things live in header files...
> I give up. Have a little think about the stack bloat, please.
>
> btw, whoever wrote that function is in need of a tab key.
Unfortunate gradual accreation of functionality.
vector_allocation_domain could perhaps be better named. Round up
this cpu to the set of cpus I need to allocate a vector on.
Eric
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH] irq: sparse irqs, fix IRQ auto-probe crash
2008-08-14 13:26 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Ingo Molnar
2008-08-14 13:31 ` [PATCH] irq: sparse irqs, fix Ingo Molnar
2008-08-14 13:36 ` [PATCH] irq: sparse irqs, fix #2 Ingo Molnar
@ 2008-08-14 13:53 ` Ingo Molnar
2008-08-14 13:57 ` [PATCH] irq: sparse irqs, export nr_irqs Ingo Molnar
` (3 subsequent siblings)
6 siblings, 0 replies; 25+ messages in thread
From: Ingo Molnar @ 2008-08-14 13:53 UTC (permalink / raw)
To: Yinghai Lu
Cc: Thomas Gleixner, H. Peter Anvin, linux-kernel, Alan Cox,
Eric W. Biederman, Andrew Morton
find below a crash fix discovered by tip/master testing.
Robustness of sparse IRQs is looking pretty good otherwise at first
glance.
Ingo
------------------>
>From a4a5ec7bbaaaab5fcb86bd348b98bfbed7c6a3b7 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 14 Aug 2008 15:48:50 +0200
Subject: [PATCH] irq: sparse irqs, fix IRQ auto-probe crash
fix:
[ 10.631533] calling yenta_socket_init+0x0/0x20
[ 10.631533] Yenta: CardBus bridge found at 0000:15:00.0 [17aa:2012]
[ 10.631533] Yenta: Using INTVAL to route CSC interrupts to PCI
[ 10.631533] Yenta: Routing CardBus interrupts to PCI
[ 10.631533] Yenta TI: socket 0000:15:00.0, mfunc 0x01d01002, devctl 0x64
[ 10.731599] BUG: unable to handle kernel NULL pointer dereference at 00000040
[ 10.731838] IP: [<c0c95b5f>] _spin_lock_irq+0xf/0x20
[ 10.732221] *pde = 00000000
[ 10.732741] Oops: 0002 [#1] SMP
[ 10.733453]
[ 10.734253] Pid: 1, comm: swapper Tainted: G W (2.6.27-rc3-tip-00173-gd7eaa4f-dirty #1)
[ 10.735188] EIP: 0060:[<c0c95b5f>] EFLAGS: 00010002 CPU: 0
[ 10.735523] EIP is at _spin_lock_irq+0xf/0x20
[ 10.735523] EAX: 00000040 EBX: 00000000 ECX: f6e04c90 EDX: 00000100
[ 10.735523] ESI: 000000df EDI: f6e04c90 EBP: f7867df0 ESP: f7867df0
[ 10.735523] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 10.735523] Process swapper (pid: 1, ti=f7867000 task=f7870000 task.ti=f7867000)
[ 10.735523] Stack: f7867e04 c0155fbd 00000000 00000000 f6e04c90 f7867e5c c0c6e319 c0f6a074
[ 10.735523] f6e04c90 000017aa 00002012 c112b648 f791f240 c112b5e0 f7867e44 c010440b
[ 10.735523] f791f240 f791f29c c112b8ec f791f240 00000000 f7867e5c c048f893 03c0b648
[ 10.735523] Call Trace:
[ 10.735523] [<c0155fbd>] ? probe_irq_on+0x3d/0x140
[ 10.735523] [<c0c6e319>] ? yenta_probe+0x529/0x640
[ 10.735523] [<c010440b>] ? mcount_call+0x5/0xa
[ 10.735523] [<c048f893>] ? pci_match_device+0xa3/0xb0
[ 10.735523] [<c048fc1e>] ? pci_device_probe+0x5e/0x80
[ 10.735523] [<c0515423>] ? driver_probe_device+0x83/0x180
[ 10.735523] [<c0515594>] ? __driver_attach+0x74/0x80
[ 10.735523] [<c0514b69>] ? bus_for_each_dev+0x49/0x70
[ 10.735523] [<c051528e>] ? driver_attach+0x1e/0x20
[ 10.735523] [<c0515520>] ? __driver_attach+0x0/0x80
[ 10.735523] [<c05150d3>] ? bus_add_driver+0x1a3/0x220
[ 10.735523] [<c048fb60>] ? pci_device_remove+0x0/0x40
[ 10.735523] [<c05157f4>] ? driver_register+0x54/0x130
[ 10.735523] [<c048fe2f>] ? __pci_register_driver+0x4f/0x90
[ 10.735523] [<c11e9419>] ? yenta_socket_init+0x19/0x20
[ 10.735523] [<c0101125>] ? do_one_initcall+0x35/0x160
[ 10.735523] [<c11e9400>] ? yenta_socket_init+0x0/0x20
[ 10.735523] [<c01391a6>] ? __queue_work+0x36/0x50
[ 10.735523] [<c013922d>] ? queue_work_on+0x3d/0x50
[ 10.735523] [<c11a2758>] ? kernel_init+0x148/0x210
[ 10.735523] [<c11a2610>] ? kernel_init+0x0/0x210
[ 10.735523] [<c01043f3>] ? kernel_thread_helper+0x7/0x10
[ 10.735523] =======================
[ 10.735523] Code: 10 38 f2 74 06 f3 90 8a 10 eb f6 5d 89 c8 c3 8d b6 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 e8 a4 e8 46 ff fa ba 00 01 00 00 90 <66> 0f c1 10 38 f2 74 06 f3 90 8a 10 eb f6 5d c3 90 55 89 e5 53
as auto-probing wants to iterate over existing irqs.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/irq/autoprobe.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/kernel/irq/autoprobe.c b/kernel/irq/autoprobe.c
index 24e1a39..6b00382 100644
--- a/kernel/irq/autoprobe.c
+++ b/kernel/irq/autoprobe.c
@@ -40,6 +40,8 @@ unsigned long probe_irq_on(void)
*/
for (i = nr_irqs-1; i > 0; i--) {
desc = irq_desc(i);
+ if (!desc)
+ continue;
spin_lock_irq(&desc->lock);
if (!desc->action && !(desc->status & IRQ_NOPROBE)) {
@@ -70,6 +72,8 @@ unsigned long probe_irq_on(void)
*/
for (i = nr_irqs-1; i > 0; i--) {
desc = irq_desc(i);
+ if (!desc)
+ continue;
spin_lock_irq(&desc->lock);
if (!desc->action && !(desc->status & IRQ_NOPROBE)) {
@@ -93,6 +97,8 @@ unsigned long probe_irq_on(void)
unsigned int status;
desc = irq_desc(i);
+ if (!desc)
+ continue;
spin_lock_irq(&desc->lock);
status = desc->status;
@@ -134,6 +140,8 @@ unsigned int probe_irq_mask(unsigned long val)
struct irq_desc *desc = irq_desc(i);
unsigned int status;
+ if (!desc)
+ continue;
spin_lock_irq(&desc->lock);
status = desc->status;
@@ -177,6 +185,8 @@ int probe_irq_off(unsigned long val)
struct irq_desc *desc = irq_desc(i);
unsigned int status;
+ if (!desc)
+ continue;
spin_lock_irq(&desc->lock);
status = desc->status;
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH] irq: sparse irqs, export nr_irqs
2008-08-14 13:26 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Ingo Molnar
` (2 preceding siblings ...)
2008-08-14 13:53 ` [PATCH] irq: sparse irqs, fix IRQ auto-probe crash Ingo Molnar
@ 2008-08-14 13:57 ` Ingo Molnar
2008-08-14 14:07 ` [PATCH] irq: sparse irqs, fix #3 Ingo Molnar
` (2 subsequent siblings)
6 siblings, 0 replies; 25+ messages in thread
From: Ingo Molnar @ 2008-08-14 13:57 UTC (permalink / raw)
To: Yinghai Lu
Cc: Thomas Gleixner, H. Peter Anvin, linux-kernel, Alan Cox,
Eric W. Biederman, Andrew Morton
>From c239ac14984518f2f3b7a920367c79bb6c3180e4 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 14 Aug 2008 15:58:26 +0200
Subject: [PATCH] irq: sparse irqs, export nr_irqs
fix:
Building modules, stage 2.
MODPOST 458 modules
ERROR: "nr_irqs" [drivers/serial/8250.ko] undefined!
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/irq/handle.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index aa889c1..ce8774b 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -56,6 +56,7 @@ handle_bad_irq(unsigned int irq, struct irq_desc *desc)
* Controller mappings for all interrupt sources:
*/
int nr_irqs = NR_IRQS;
+EXPORT_SYMBOL_GPL(nr_irqs);
#ifdef CONFIG_HAVE_DYN_ARRAY
static struct irq_desc irq_desc_init = {
^ permalink raw reply related [flat|nested] 25+ messages in thread* [PATCH] irq: sparse irqs, fix #3
2008-08-14 13:26 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Ingo Molnar
` (3 preceding siblings ...)
2008-08-14 13:57 ` [PATCH] irq: sparse irqs, export nr_irqs Ingo Molnar
@ 2008-08-14 14:07 ` Ingo Molnar
2008-08-14 17:34 ` Yinghai Lu
2008-08-14 19:01 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Yinghai Lu
2008-08-29 21:16 ` Andrew Morton
6 siblings, 1 reply; 25+ messages in thread
From: Ingo Molnar @ 2008-08-14 14:07 UTC (permalink / raw)
To: Yinghai Lu
Cc: Thomas Gleixner, H. Peter Anvin, linux-kernel, Alan Cox,
Eric W. Biederman, Andrew Morton
>From 1b53f0444df394e4448ba56694f0bc4dda2bece0 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 14 Aug 2008 16:07:04 +0200
Subject: [PATCH] irq: sparse irqs, fix #3
fix non-APIC UP build:
arch/x86/kernel/built-in.o: In function `setup_arch':
: undefined reference to `pin_map_size'
arch/x86/kernel/built-in.o: In function `setup_arch':
: undefined reference to `first_free_entry'
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/setup.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 24e984e..8318a35 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -863,8 +863,10 @@ void __init setup_arch(char **cmdline_p)
nr_irqs = 32 * nr_cpu_ids + 224;
init_cpu_to_node();
#endif
+#ifdef CONFIG_X86_LOCAL_APIC
pin_map_size = nr_irqs * 2;
first_free_entry = nr_irqs;
+#endif
init_apic_mappings();
ioapic_init_mappings();
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH] irq: sparse irqs, fix #3
2008-08-14 14:07 ` [PATCH] irq: sparse irqs, fix #3 Ingo Molnar
@ 2008-08-14 17:34 ` Yinghai Lu
0 siblings, 0 replies; 25+ messages in thread
From: Yinghai Lu @ 2008-08-14 17:34 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, H. Peter Anvin, linux-kernel, Alan Cox,
Eric W. Biederman, Andrew Morton
On Thu, Aug 14, 2008 at 7:07 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> From 1b53f0444df394e4448ba56694f0bc4dda2bece0 Mon Sep 17 00:00:00 2001
> From: Ingo Molnar <mingo@elte.hu>
> Date: Thu, 14 Aug 2008 16:07:04 +0200
> Subject: [PATCH] irq: sparse irqs, fix #3
>
> fix non-APIC UP build:
>
> arch/x86/kernel/built-in.o: In function `setup_arch':
> : undefined reference to `pin_map_size'
> arch/x86/kernel/built-in.o: In function `setup_arch':
> : undefined reference to `first_free_entry'
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
> arch/x86/kernel/setup.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 24e984e..8318a35 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -863,8 +863,10 @@ void __init setup_arch(char **cmdline_p)
> nr_irqs = 32 * nr_cpu_ids + 224;
> init_cpu_to_node();
> #endif
> +#ifdef CONFIG_X86_LOCAL_APIC
> pin_map_size = nr_irqs * 2;
> first_free_entry = nr_irqs;
> +#endif
>
> init_apic_mappings();
> ioapic_init_mappings();
>
we don't need pin_map_size and first_free_entry after 64 and 32 bit
all put irq_2_pin in irq_cfg.
need to remove them.
YH
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-14 13:26 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Ingo Molnar
` (4 preceding siblings ...)
2008-08-14 14:07 ` [PATCH] irq: sparse irqs, fix #3 Ingo Molnar
@ 2008-08-14 19:01 ` Yinghai Lu
2008-08-14 20:05 ` Eric W. Biederman
2008-08-15 12:18 ` Ingo Molnar
2008-08-29 21:16 ` Andrew Morton
6 siblings, 2 replies; 25+ messages in thread
From: Yinghai Lu @ 2008-08-14 19:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, H. Peter Anvin, linux-kernel, Alan Cox,
Eric W. Biederman, Andrew Morton
On Thu, Aug 14, 2008 at 6:26 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> (lkml Cc:-ed)
>
> * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
>> v10: make the x86 32 bit support sparse_irq too.
>> also make remove irqbalance in kernel for 32 bit
>> and make 32 bit support per_cpu vector. so start merging or io_apic_xx.c
>>
>> 01-03 is some fix for current tree
>> 04: is revert for one patch hide in sched/ and tip/master
>>
>> based on tip/master
>>
>> to do:
>> merge io_apic_xx.c
>
> ok, i've created a new tip/irq/sparseirq topic branch for this.
>
> Could you please send future updates against:
>
> git-checkout tip/master
> git-merge tip/irq/sparseirq
>
> Not yet integrated into tip/master, i've still got some other backlog.
>
> A couple of observations about the general structure of the sparse irqs
> code:
>
> - the new APIs should probably live in mm/bootmem.c not in init/main.c,
> and in bootmem.h. Also, it should be outlined clearly why this new API
> is needed as a wrapper ontop of existing bootmem mechanisms.
move
pre_alloc_dyn_array, per_cpu_dyn_array_size, per_cpu_alloc_dyn_array
to mm/bootmem.c?
>
> - the #ifdef complications, while fine for migration, should be
> eliminated. Could we introduce some compatible form for the
> definition/allocation APIs that work even if an architecture still
> uses a flat irq array? That would remove most of the uglinesses.
# git grep CONFIG_HAVE_DYN_ARRAY | wc -l
9
#git grep CONFIG_HAVE_SPARSE_IRQ | wc -l
39
arch/x86/kernel/io_apic_32.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
arch/x86/kernel/io_apic_32.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
arch/x86/kernel/io_apic_64.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
arch/x86/kernel/io_apic_64.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
arch/x86/kernel/irq_32.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
arch/x86/kernel/irq_64.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
drivers/char/random.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
drivers/char/random.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
drivers/pci/intr_remapping.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
drivers/pci/intr_remapping.c:#else /* !CONFIG_HAVE_SPARSE_IRQ */
drivers/pci/intr_remapping.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
include/linux/irq.h:#if defined(CONFIG_INTR_REMAP) &&
defined(CONFIG_HAVE_SPARSE_IRQ)
include/linux/irq.h:#ifndef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/handle.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
kernel/irq/handle.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/manage.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/manage.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
kernel/irq/migration.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
because try to avoid more api to be changed to take irq_desc as parameter.
>
> - some of the irq < 16 checks in x86 look a bit ugly, can we do anything
> about them?
is_legacy_irq(irq) ? or legacy_irq(irq)?
>
> - i think as a final-ish commit we should just remove the dyn-array
> define and make all architectures use this facility. You converted
> most of them - how many are still missing? Sparse-irq is more
> intrusive so that should probably stay a Kconfig knob.
so when config_sparse_irq is not selected, need to use dyn_array to
allocate irq_desc and irq_cfg, or just static array?
>
> - there was one aspect of NR_IRQS that was nice and useful: it acted as
> a sanity check against BIOS bugs and driver bugs that pass in some
> irrealistically high irq number. Now we'll just try to allocate some
> really high IRQ and accept it. I _think_ there should be a single,
> simple 'absolute maximum IRQ number' define which should set the
> maximum possible IRQ number. Lets call it NR_IRQS_MAX or so, and set
> it to NR_CPUS*NR_IO_APICS*224 or so?
when sparse_irq is used, irq is [0, -1U]
driver could be irq_desc(irq) to check if irq is valid or not. and use
irq_desc_with_new(new) to get a new one.
when generic_hardirqs is not used (s390, m68k, sparc), we need to
create some stubs in linux/interrupt.h for them
>
> - i'm a bit worried about linecount increase in general:
>
> 247 files changed, 3671 insertions(+), 2052 deletions(-)
>
> could we work on reducing that somewhat? The new infrastructure bits
> in mm/* and kernel/irq/* will be unavoidable, what we should
> concentrate on is to make usage of the new facility just as
> straightforward, easy and compact as the old irq_desc[] usages.
before that we could use get_irq_desc() and get_irq_desc_without_new()
and according to eric, i changed that to irq_desc_with_new and irq_desc().
so the array irq_desc[] need to be changed to irq_descX[]
( or *irq_desc to *irq_descX for dyn_array)
>
> A worst-case example is drivers/char/random.c: the
> CONFIG_HAVE_SPARSE_IRQ and CONFIG_HAVE_DYN_ARRAY #ifdef jungle is not
> acceptable. I think the best way out is to convert the whole kernel to
> the new facilities (as safely as possible, without breaking other
> architectures), and making sure that the end result is easy to
> understand and intuitive.
# grep CONFIG_HAVE_ drivers/char/random.c
#ifndef CONFIG_HAVE_SPARSE_IRQ
#ifdef CONFIG_HAVE_DYN_ARRAY
#ifndef CONFIG_HAVE_SPARSE_IRQ
just want to make other arch is untouched.
>
> so i dont mind the current code as long as the extra complications are
> temporary during a safe conversion - but we should work on eliminating
> all those complications before thinking about upstream merging.
>
> Ingo
>
> -------------------->
> the irq/sparseirq git tree can be picked up from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git irq/sparseirq
>
Thanks
Yinghai Lu
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-14 19:01 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Yinghai Lu
@ 2008-08-14 20:05 ` Eric W. Biederman
2008-08-14 20:42 ` Yinghai Lu
2008-08-15 12:18 ` Ingo Molnar
1 sibling, 1 reply; 25+ messages in thread
From: Eric W. Biederman @ 2008-08-14 20:05 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, linux-kernel,
Alan Cox, Andrew Morton
"Yinghai Lu" <yhlu.kernel@gmail.com> writes:
> On Thu, Aug 14, 2008 at 6:26 AM, Ingo Molnar <mingo@elte.hu> wrote:
>>
>> (lkml Cc:-ed)
>>
>> * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>>
>>> v10: make the x86 32 bit support sparse_irq too.
>>> also make remove irqbalance in kernel for 32 bit
>>> and make 32 bit support per_cpu vector. so start merging or io_apic_xx.c
>>>
>>> 01-03 is some fix for current tree
>>> 04: is revert for one patch hide in sched/ and tip/master
>>>
>>> based on tip/master
>>>
>>> to do:
>>> merge io_apic_xx.c
>>
>> ok, i've created a new tip/irq/sparseirq topic branch for this.
>>
>> Could you please send future updates against:
>>
>> git-checkout tip/master
>> git-merge tip/irq/sparseirq
>>
>> Not yet integrated into tip/master, i've still got some other backlog.
>>
>> A couple of observations about the general structure of the sparse irqs
>> code:
>>
>> - the new APIs should probably live in mm/bootmem.c not in init/main.c,
>> and in bootmem.h. Also, it should be outlined clearly why this new API
>> is needed as a wrapper ontop of existing bootmem mechanisms.
>
> move
> pre_alloc_dyn_array, per_cpu_dyn_array_size, per_cpu_alloc_dyn_array
> to mm/bootmem.c?
>
>>
>> - the #ifdef complications, while fine for migration, should be
>> eliminated. Could we introduce some compatible form for the
>> definition/allocation APIs that work even if an architecture still
>> uses a flat irq array? That would remove most of the uglinesses.
> # git grep CONFIG_HAVE_DYN_ARRAY | wc -l
> 9
>
> #git grep CONFIG_HAVE_SPARSE_IRQ | wc -l
> 39
>
> arch/x86/kernel/io_apic_32.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
> arch/x86/kernel/io_apic_32.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> arch/x86/kernel/io_apic_64.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
> arch/x86/kernel/io_apic_64.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> arch/x86/kernel/irq_32.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> arch/x86/kernel/irq_64.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> drivers/char/random.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> drivers/char/random.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> drivers/pci/intr_remapping.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> drivers/pci/intr_remapping.c:#else /* !CONFIG_HAVE_SPARSE_IRQ */
> drivers/pci/intr_remapping.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
> include/linux/irq.h:#if defined(CONFIG_INTR_REMAP) &&
> defined(CONFIG_HAVE_SPARSE_IRQ)
> include/linux/irq.h:#ifndef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
> kernel/irq/handle.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/manage.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/manage.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/migration.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>
> because try to avoid more api to be changed to take irq_desc as parameter.
>
>>
>> - some of the irq < 16 checks in x86 look a bit ugly, can we do anything
>> about them?
>
> is_legacy_irq(irq) ? or legacy_irq(irq)?
>
>>
>> - i think as a final-ish commit we should just remove the dyn-array
>> define and make all architectures use this facility. You converted
>> most of them - how many are still missing? Sparse-irq is more
>> intrusive so that should probably stay a Kconfig knob.
>
> so when config_sparse_irq is not selected, need to use dyn_array to
> allocate irq_desc and irq_cfg, or just static array?
>
>>
>> - there was one aspect of NR_IRQS that was nice and useful: it acted as
>> a sanity check against BIOS bugs and driver bugs that pass in some
>> irrealistically high irq number. Now we'll just try to allocate some
>> really high IRQ and accept it. I _think_ there should be a single,
>> simple 'absolute maximum IRQ number' define which should set the
>> maximum possible IRQ number. Lets call it NR_IRQS_MAX or so, and set
>> it to NR_CPUS*NR_IO_APICS*224 or so?
We may want an is_valid_isa_irq() for drivers. Otherwise drivers
should not be passing in irqs. And the request_irq path should
valid the irq number but it should not allocate it. So we will
have failures with invalid irq numbers.
For acpi, mptables and the like we can easily have a check for some
reasonably high value if there is value in that. Last I looked parts
of that code were using numbers like 1024 and 4096 already.
> when sparse_irq is used, irq is [0, -1U]
> driver could be irq_desc(irq) to check if irq is valid or not. and use
> irq_desc_with_new(new) to get a new one.
Note that request_irq should do this for free.
> when generic_hardirqs is not used (s390, m68k, sparc), we need to
> create some stubs in linux/interrupt.h for them
s390 is weird. I'm not even convinced they use linux/interrupt.h
Yep. If we need more than the proper checks in request_irq.
>> - i'm a bit worried about linecount increase in general:
>>
>> 247 files changed, 3671 insertions(+), 2052 deletions(-)
>>
>> could we work on reducing that somewhat? The new infrastructure bits
>> in mm/* and kernel/irq/* will be unavoidable, what we should
>> concentrate on is to make usage of the new facility just as
>> straightforward, easy and compact as the old irq_desc[] usages.
> before that we could use get_irq_desc() and get_irq_desc_without_new()
> and according to eric, i changed that to irq_desc_with_new and irq_desc().
>
> so the array irq_desc[] need to be changed to irq_descX[]
> ( or *irq_desc to *irq_descX for dyn_array)
My mistake. irq_desc() is a bad name for the conversion method
because it conflicts like that. I really just did not want something
wordy, or something that suggests you need to call put_irq_desc. BothÜ
of which get_irq_desc() are.
What I wound up using in my tree is a little different.
I introduced an opaque/empty structure: struct irq to be used in places
where we need pointers instead of an integer irq number in the interfaces.
I have a version of the genirq api that works on struct irq instead of
unsigned int irq.
I have functions:
struct irq * to_irq(unsigned int nr);
struct irq_desc *to_idesc(struct irq *);
unsigned int irq_nr(struct irq *irq);
Is there any reason why the migration path for architectures can not be:
Until they are converted:
#define NR_IRQS and use the irq_desc array.
If they are just using a dynamically allocated array.
#define NR_IRQS nr_irqs
Once we kill the array entirely.
#undef NR_IRQS or
#define NR_IRQS 0xfffff000
>> A worst-case example is drivers/char/random.c: the
>> CONFIG_HAVE_SPARSE_IRQ and CONFIG_HAVE_DYN_ARRAY #ifdef jungle is not
>> acceptable. I think the best way out is to convert the whole kernel to
>> the new facilities (as safely as possible, without breaking other
>> architectures), and making sure that the end result is easy to
>> understand and intuitive.
>
> # grep CONFIG_HAVE_ drivers/char/random.c
> #ifndef CONFIG_HAVE_SPARSE_IRQ
> #ifdef CONFIG_HAVE_DYN_ARRAY
> #ifndef CONFIG_HAVE_SPARSE_IRQ
>
> just want to make other arch is untouched.
It doesn't matter. If you look only genirq arches use use random irqs.
Eric
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-14 20:05 ` Eric W. Biederman
@ 2008-08-14 20:42 ` Yinghai Lu
2008-08-14 21:24 ` Yinghai Lu
2008-08-14 23:55 ` Eric W. Biederman
0 siblings, 2 replies; 25+ messages in thread
From: Yinghai Lu @ 2008-08-14 20:42 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, linux-kernel,
Alan Cox, Andrew Morton
On Thu, Aug 14, 2008 at 1:05 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>
>> On Thu, Aug 14, 2008 at 6:26 AM, Ingo Molnar <mingo@elte.hu> wrote:
>>>
>>> (lkml Cc:-ed)
>>>
>>> * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>>>
>>>> v10: make the x86 32 bit support sparse_irq too.
>>>> also make remove irqbalance in kernel for 32 bit
>>>> and make 32 bit support per_cpu vector. so start merging or io_apic_xx.c
>>>>
>>>> 01-03 is some fix for current tree
>>>> 04: is revert for one patch hide in sched/ and tip/master
>>>>
>>>> based on tip/master
>>>>
>>>> to do:
>>>> merge io_apic_xx.c
>>>
>>> ok, i've created a new tip/irq/sparseirq topic branch for this.
>>>
>>> Could you please send future updates against:
>>>
>>> git-checkout tip/master
>>> git-merge tip/irq/sparseirq
>>>
>>> Not yet integrated into tip/master, i've still got some other backlog.
>>>
>>> A couple of observations about the general structure of the sparse irqs
>>> code:
>>>
>>> - the new APIs should probably live in mm/bootmem.c not in init/main.c,
>>> and in bootmem.h. Also, it should be outlined clearly why this new API
>>> is needed as a wrapper ontop of existing bootmem mechanisms.
>>
>> move
>> pre_alloc_dyn_array, per_cpu_dyn_array_size, per_cpu_alloc_dyn_array
>> to mm/bootmem.c?
>>
>>>
>>> - the #ifdef complications, while fine for migration, should be
>>> eliminated. Could we introduce some compatible form for the
>>> definition/allocation APIs that work even if an architecture still
>>> uses a flat irq array? That would remove most of the uglinesses.
>> # git grep CONFIG_HAVE_DYN_ARRAY | wc -l
>> 9
>>
>> #git grep CONFIG_HAVE_SPARSE_IRQ | wc -l
>> 39
>>
>> arch/x86/kernel/io_apic_32.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
>> arch/x86/kernel/io_apic_32.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
>> arch/x86/kernel/io_apic_64.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
>> arch/x86/kernel/io_apic_64.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
>> arch/x86/kernel/irq_32.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> arch/x86/kernel/irq_64.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> drivers/char/random.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
>> drivers/char/random.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
>> drivers/pci/intr_remapping.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> drivers/pci/intr_remapping.c:#else /* !CONFIG_HAVE_SPARSE_IRQ */
>> drivers/pci/intr_remapping.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
>> fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> include/linux/irq.h:#if defined(CONFIG_INTR_REMAP) &&
>> defined(CONFIG_HAVE_SPARSE_IRQ)
>> include/linux/irq.h:#ifndef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/handle.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
>> kernel/irq/handle.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/manage.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/manage.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>> kernel/irq/migration.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>>
>> because try to avoid more api to be changed to take irq_desc as parameter.
>>
>>>
>>> - some of the irq < 16 checks in x86 look a bit ugly, can we do anything
>>> about them?
>>
>> is_legacy_irq(irq) ? or legacy_irq(irq)?
>
>
>>
>>>
>>> - i think as a final-ish commit we should just remove the dyn-array
>>> define and make all architectures use this facility. You converted
>>> most of them - how many are still missing? Sparse-irq is more
>>> intrusive so that should probably stay a Kconfig knob.
>>
>> so when config_sparse_irq is not selected, need to use dyn_array to
>> allocate irq_desc and irq_cfg, or just static array?
>>
>>>
>>> - there was one aspect of NR_IRQS that was nice and useful: it acted as
>>> a sanity check against BIOS bugs and driver bugs that pass in some
>>> irrealistically high irq number. Now we'll just try to allocate some
>>> really high IRQ and accept it. I _think_ there should be a single,
>>> simple 'absolute maximum IRQ number' define which should set the
>>> maximum possible IRQ number. Lets call it NR_IRQS_MAX or so, and set
>>> it to NR_CPUS*NR_IO_APICS*224 or so?
>
> We may want an is_valid_isa_irq() for drivers. Otherwise drivers
> should not be passing in irqs. And the request_irq path should
> valid the irq number but it should not allocate it. So we will
> have failures with invalid irq numbers.
>
> For acpi, mptables and the like we can easily have a check for some
> reasonably high value if there is value in that. Last I looked parts
> of that code were using numbers like 1024 and 4096 already.
>
>> when sparse_irq is used, irq is [0, -1U]
>> driver could be irq_desc(irq) to check if irq is valid or not. and use
>> irq_desc_with_new(new) to get a new one.
>
> Note that request_irq should do this for free.
>
>> when generic_hardirqs is not used (s390, m68k, sparc), we need to
>> create some stubs in linux/interrupt.h for them
>
> s390 is weird. I'm not even convinced they use linux/interrupt.h
>
> Yep. If we need more than the proper checks in request_irq.
>
>>> - i'm a bit worried about linecount increase in general:
>>>
>>> 247 files changed, 3671 insertions(+), 2052 deletions(-)
>>>
>>> could we work on reducing that somewhat? The new infrastructure bits
>>> in mm/* and kernel/irq/* will be unavoidable, what we should
>>> concentrate on is to make usage of the new facility just as
>>> straightforward, easy and compact as the old irq_desc[] usages.
>> before that we could use get_irq_desc() and get_irq_desc_without_new()
>> and according to eric, i changed that to irq_desc_with_new and irq_desc().
>>
>> so the array irq_desc[] need to be changed to irq_descX[]
>> ( or *irq_desc to *irq_descX for dyn_array)
>
> My mistake. irq_desc() is a bad name for the conversion method
> because it conflicts like that. I really just did not want something
> wordy, or something that suggests you need to call put_irq_desc. BothÜ
> of which get_irq_desc() are.
it took me one day to change them. anyway irq_desc() is better than get_irq_desc
>
> What I wound up using in my tree is a little different.
>
> I introduced an opaque/empty structure: struct irq to be used in places
> where we need pointers instead of an integer irq number in the interfaces.
>
> I have a version of the genirq api that works on struct irq instead of
> unsigned int irq.
>
> I have functions:
> struct irq * to_irq(unsigned int nr);
> struct irq_desc *to_idesc(struct irq *);
> unsigned int irq_nr(struct irq *irq);
struct irq {
unsigned int nr;
struct irq_desc *idesc;
}
?
>
> Is there any reason why the migration path for architectures can not be:
> Until they are converted:
> #define NR_IRQS and use the irq_desc array.
>
> If they are just using a dynamically allocated array.
> #define NR_IRQS nr_irqs
>
> Once we kill the array entirely.
> #undef NR_IRQS or
> #define NR_IRQS 0xfffff000
why not use -1U here?
YH
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-14 20:42 ` Yinghai Lu
@ 2008-08-14 21:24 ` Yinghai Lu
2008-08-15 0:11 ` Eric W. Biederman
2008-08-14 23:55 ` Eric W. Biederman
1 sibling, 1 reply; 25+ messages in thread
From: Yinghai Lu @ 2008-08-14 21:24 UTC (permalink / raw)
To: Eric W. Biederman, Ingo Molnar
Cc: Thomas Gleixner, H. Peter Anvin, linux-kernel, Alan Cox,
Andrew Morton
find something interesting:
found new irq_cfg for irq 20
0 add_pin_to_irq: irq 20 --> apic 0 pin 20
assign_irq_vector: irq 20 vector 0x59 cpu 5
IOAPIC[0]: Set routing entry (0-20 -> 0x59 -> IRQ 20 Mode:1 Active:1)
found new irq_desc for irq 20
pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20
IO APIC #0......
.... register #00: 00000000
....... : physical APIC id: 00
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 00170011
....... : max redirection entries: 0017
....... : PRQ implemented: 0
....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
...
14 09 1 1 0 1 0 0 0 59
...
ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
do_IRQ: cannot handle IRQ -1 vector 0x59 cpu 0
------------[ cut here ]------------
Kernel BUG at 40206b11 [verbose debug info unavailable]
invalid opcode: 0000 [#1] SMP
Modules linked in:
Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty #23)
EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
EIP is at do_IRQ+0x6b/0xae
EAX: 00000032 EBX: 00001d28 ECX: 00003434 EDX: 00000046
ESI: 00000000 EDI: 00000059 EBP: c7a37d3c ESP: c7a37d14
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)
Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff c421bd20
c7a37d9c c7a37dac c7a37d7c 4020555f c421bd20 00000000 c421bd20 c7a37d9c
c7a37dac c7a37d7c 40b717f8 0000007b 0000007b 000000d8 ffffffa6 4080db6c
Call Trace:
[<4020555f>] ? common_interrupt+0x23/0x28
it is on 16cores system with 32bit bigsmp, so it is using phy_flat
cpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)
but io_apic controller deliver that interrupt to cpu0 (with apicid =
4) instead of cpu 5 (with apic id = 9)
look at the 64 bit, TARGET_CPUS for phys_flat is cpu_online_map
and 32bit bigsmp TARGET_CPUS is only one cpu set and rotating with online cpu...
Change 32bit bigsmp TARGE_CPUS ?
YH
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-14 21:24 ` Yinghai Lu
@ 2008-08-15 0:11 ` Eric W. Biederman
2008-08-15 0:49 ` Yinghai Lu
0 siblings, 1 reply; 25+ messages in thread
From: Eric W. Biederman @ 2008-08-15 0:11 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, linux-kernel,
Alan Cox, Andrew Morton
"Yinghai Lu" <yhlu.kernel@gmail.com> writes:
> find something interesting:
>
> found new irq_cfg for irq 20
> 0 add_pin_to_irq: irq 20 --> apic 0 pin 20
> assign_irq_vector: irq 20 vector 0x59 cpu 5
> IOAPIC[0]: Set routing entry (0-20 -> 0x59 -> IRQ 20 Mode:1 Active:1)
> found new irq_desc for irq 20
> pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20
>
> IO APIC #0......
> .... register #00: 00000000
> ....... : physical APIC id: 00
> ....... : Delivery Type: 0
> ....... : LTS : 0
> .... register #01: 00170011
> ....... : max redirection entries: 0017
> ....... : PRQ implemented: 0
> ....... : IO APIC version: 0011
> .... register #02: 00000000
> ....... : arbitration: 00
> .... IRQ redirection table:
> NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
> ...
> 14 09 1 1 0 1 0 0 0 59
> ...
>
> ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
> do_IRQ: cannot handle IRQ -1 vector 0x59 cpu 0
> ------------[ cut here ]------------
> Kernel BUG at 40206b11 [verbose debug info unavailable]
> invalid opcode: 0000 [#1] SMP
> Modules linked in:
>
> Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty #23)
> EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
> EIP is at do_IRQ+0x6b/0xae
> EAX: 00000032 EBX: 00001d28 ECX: 00003434 EDX: 00000046
> ESI: 00000000 EDI: 00000059 EBP: c7a37d3c ESP: c7a37d14
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)
> Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff c421bd20
> c7a37d9c c7a37dac c7a37d7c 4020555f c421bd20 00000000 c421bd20 c7a37d9c
> c7a37dac c7a37d7c 40b717f8 0000007b 0000007b 000000d8 ffffffa6 4080db6c
> Call Trace:
> [<4020555f>] ? common_interrupt+0x23/0x28
>
>
> it is on 16cores system with 32bit bigsmp, so it is using phy_flat
> cpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)
>
> but io_apic controller deliver that interrupt to cpu0 (with apicid =
> 4) instead of cpu 5 (with apic id = 9)
>
> look at the 64 bit, TARGET_CPUS for phys_flat is cpu_online_map
>
> and 32bit bigsmp TARGET_CPUS is only one cpu set and rotating with online cpu...
>
> Change 32bit bigsmp TARGE_CPUS ?
Set vector_allocation_domain to CPU_MASK_ALL on 32bit. That doesn't give us
the benefit of per cpu vectors right now, but in my research there has not
been a 32bit kernel yet that has needed it. We have never shared vectors
between 2 gsi on 32bit x86, we have only collapsed the irq space.
On x86_64 before I did the per cpu vectors there were machines that
combined multiple interrupt sources (gsi) into the same irq. So
x86_64 has needed the per cpu vectors.
Which means in practice that the irq compression on x86_32 was just a hack to
with not having enough irq_desc entries. I wish I had realized that last
time we were talking, as we could have unilaterally ripped out all of that
code as completely unnecessary on x86 and just bumped NR_IRQS to 1024 on
the boxes that had more than 256 gsis.
Eric
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-15 0:11 ` Eric W. Biederman
@ 2008-08-15 0:49 ` Yinghai Lu
2008-08-15 1:01 ` Eric W. Biederman
2008-08-15 1:09 ` Eric W. Biederman
0 siblings, 2 replies; 25+ messages in thread
From: Yinghai Lu @ 2008-08-15 0:49 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, linux-kernel,
Alan Cox, Andrew Morton
On Thu, Aug 14, 2008 at 5:11 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>
>> find something interesting:
>>
>> found new irq_cfg for irq 20
>> 0 add_pin_to_irq: irq 20 --> apic 0 pin 20
>> assign_irq_vector: irq 20 vector 0x59 cpu 5
>> IOAPIC[0]: Set routing entry (0-20 -> 0x59 -> IRQ 20 Mode:1 Active:1)
>> found new irq_desc for irq 20
>> pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20
>>
>> IO APIC #0......
>> .... register #00: 00000000
>> ....... : physical APIC id: 00
>> ....... : Delivery Type: 0
>> ....... : LTS : 0
>> .... register #01: 00170011
>> ....... : max redirection entries: 0017
>> ....... : PRQ implemented: 0
>> ....... : IO APIC version: 0011
>> .... register #02: 00000000
>> ....... : arbitration: 00
>> .... IRQ redirection table:
>> NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
>> ...
>> 14 09 1 1 0 1 0 0 0 59
>> ...
>>
>> ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
>> do_IRQ: cannot handle IRQ -1 vector 0x59 cpu 0
>> ------------[ cut here ]------------
>> Kernel BUG at 40206b11 [verbose debug info unavailable]
>> invalid opcode: 0000 [#1] SMP
>> Modules linked in:
>>
>> Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty #23)
>> EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
>> EIP is at do_IRQ+0x6b/0xae
>> EAX: 00000032 EBX: 00001d28 ECX: 00003434 EDX: 00000046
>> ESI: 00000000 EDI: 00000059 EBP: c7a37d3c ESP: c7a37d14
>> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
>> Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)
>> Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff c421bd20
>> c7a37d9c c7a37dac c7a37d7c 4020555f c421bd20 00000000 c421bd20 c7a37d9c
>> c7a37dac c7a37d7c 40b717f8 0000007b 0000007b 000000d8 ffffffa6 4080db6c
>> Call Trace:
>> [<4020555f>] ? common_interrupt+0x23/0x28
>>
>>
>> it is on 16cores system with 32bit bigsmp, so it is using phy_flat
>> cpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)
>>
>> but io_apic controller deliver that interrupt to cpu0 (with apicid =
>> 4) instead of cpu 5 (with apic id = 9)
>>
>> look at the 64 bit, TARGET_CPUS for phys_flat is cpu_online_map
>>
>> and 32bit bigsmp TARGET_CPUS is only one cpu set and rotating with online cpu...
>>
>> Change 32bit bigsmp TARGE_CPUS ?
>
> Set vector_allocation_domain to CPU_MASK_ALL on 32bit. That doesn't give us
> the benefit of per cpu vectors right now, but in my research there has not
> been a 32bit kernel yet that has needed it. We have never shared vectors
> between 2 gsi on 32bit x86, we have only collapsed the irq space.
TARGET_CPUS only used by ioapic_xx.c
vector_allocator_domain will return cpumask_of_cpu(cpu)..
>
> On x86_64 before I did the per cpu vectors there were machines that
> combined multiple interrupt sources (gsi) into the same irq. So
> x86_64 has needed the per cpu vectors.
>
> Which means in practice that the irq compression on x86_32 was just a hack to
> with not having enough irq_desc entries. I wish I had realized that last
> time we were talking, as we could have unilaterally ripped out all of that
> code as completely unnecessary on x86 and just bumped NR_IRQS to 1024 on
> the boxes that had more than 256 gsis.
now 32bit and 64bit is the same page now... (bigsmp == phys_flat)...
will continue to merge io_apic_xx.c
YH
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-15 0:49 ` Yinghai Lu
@ 2008-08-15 1:01 ` Eric W. Biederman
2008-08-15 1:41 ` Yinghai Lu
2008-08-15 1:09 ` Eric W. Biederman
1 sibling, 1 reply; 25+ messages in thread
From: Eric W. Biederman @ 2008-08-15 1:01 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, linux-kernel,
Alan Cox, Andrew Morton
"Yinghai Lu" <yhlu.kernel@gmail.com> writes:
> On Thu, Aug 14, 2008 at 5:11 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>>
>>> find something interesting:
>>>
>>> found new irq_cfg for irq 20
>>> 0 add_pin_to_irq: irq 20 --> apic 0 pin 20
>>> assign_irq_vector: irq 20 vector 0x59 cpu 5
>>> IOAPIC[0]: Set routing entry (0-20 -> 0x59 -> IRQ 20 Mode:1 Active:1)
>>> found new irq_desc for irq 20
>>> pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20
>>>
>>> IO APIC #0......
>>> .... register #00: 00000000
>>> ....... : physical APIC id: 00
>>> ....... : Delivery Type: 0
>>> ....... : LTS : 0
>>> .... register #01: 00170011
>>> ....... : max redirection entries: 0017
>>> ....... : PRQ implemented: 0
>>> ....... : IO APIC version: 0011
>>> .... register #02: 00000000
>>> ....... : arbitration: 00
>>> .... IRQ redirection table:
>>> NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
>>> ...
>>> 14 09 1 1 0 1 0 0 0 59
>>> ...
>>>
>>> ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
>>> do_IRQ: cannot handle IRQ -1 vector 0x59 cpu 0
>>> ------------[ cut here ]------------
>>> Kernel BUG at 40206b11 [verbose debug info unavailable]
>>> invalid opcode: 0000 [#1] SMP
>>> Modules linked in:
>>>
>>> Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty
> #23)
>>> EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
>>> EIP is at do_IRQ+0x6b/0xae
>>> EAX: 00000032 EBX: 00001d28 ECX: 00003434 EDX: 00000046
>>> ESI: 00000000 EDI: 00000059 EBP: c7a37d3c ESP: c7a37d14
>>> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
>>> Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)
>>> Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff
> c421bd20
>>> c7a37d9c c7a37dac c7a37d7c 4020555f c421bd20 00000000 c421bd20 c7a37d9c
>>> c7a37dac c7a37d7c 40b717f8 0000007b 0000007b 000000d8 ffffffa6 4080db6c
>>> Call Trace:
>>> [<4020555f>] ? common_interrupt+0x23/0x28
>>>
>>>
>>> it is on 16cores system with 32bit bigsmp, so it is using phy_flat
>>> cpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)
>>>
>>> but io_apic controller deliver that interrupt to cpu0 (with apicid =
>>> 4) instead of cpu 5 (with apic id = 9)
>>>
>>> look at the 64 bit, TARGET_CPUS for phys_flat is cpu_online_map
>>>
>>> and 32bit bigsmp TARGET_CPUS is only one cpu set and rotating with online
> cpu...
>>>
>>> Change 32bit bigsmp TARGE_CPUS ?
>>
>> Set vector_allocation_domain to CPU_MASK_ALL on 32bit. That doesn't give us
>> the benefit of per cpu vectors right now, but in my research there has not
>> been a 32bit kernel yet that has needed it. We have never shared vectors
>> between 2 gsi on 32bit x86, we have only collapsed the irq space.
>
> TARGET_CPUS only used by ioapic_xx.c
Target cpus is a hint to tell us what to do if the user has not.
> vector_allocator_domain will return cpumask_of_cpu(cpu)..
Which is a bug for lowest priority delivery mode. But you said
phys_flat and not flat. Which sounds like bigsmp last I read it.
>> On x86_64 before I did the per cpu vectors there were machines that
>> combined multiple interrupt sources (gsi) into the same irq. So
>> x86_64 has needed the per cpu vectors.
>>
>> Which means in practice that the irq compression on x86_32 was just a hack to
>> with not having enough irq_desc entries. I wish I had realized that last
>> time we were talking, as we could have unilaterally ripped out all of that
>> code as completely unnecessary on x86 and just bumped NR_IRQS to 1024 on
>> the boxes that had more than 256 gsis.
>
> now 32bit and 64bit is the same page now... (bigsmp == phys_flat)...
>
> will continue to merge io_apic_xx.c
Hmm. In that case I will ask that you look at all of the pieces of
irq migration code, and make certain that they have all come from x86_64.
There were a lot of little changes that had to be made. If this is
an irq migration problem it should be easy to find, by stressing irq
migration in user space. You probably want to turn off the in kernel
irq balancer while debugging this.
Eric
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-15 1:01 ` Eric W. Biederman
@ 2008-08-15 1:41 ` Yinghai Lu
2008-08-15 2:33 ` Eric W. Biederman
0 siblings, 1 reply; 25+ messages in thread
From: Yinghai Lu @ 2008-08-15 1:41 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, linux-kernel,
Alan Cox, Andrew Morton
On Thu, Aug 14, 2008 at 6:01 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>
>> On Thu, Aug 14, 2008 at 5:11 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>>>
>>>> find something interesting:
>>>>
>>>> found new irq_cfg for irq 20
>>>> 0 add_pin_to_irq: irq 20 --> apic 0 pin 20
>>>> assign_irq_vector: irq 20 vector 0x59 cpu 5
>>>> IOAPIC[0]: Set routing entry (0-20 -> 0x59 -> IRQ 20 Mode:1 Active:1)
>>>> found new irq_desc for irq 20
>>>> pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20
>>>>
>>>> IO APIC #0......
>>>> .... register #00: 00000000
>>>> ....... : physical APIC id: 00
>>>> ....... : Delivery Type: 0
>>>> ....... : LTS : 0
>>>> .... register #01: 00170011
>>>> ....... : max redirection entries: 0017
>>>> ....... : PRQ implemented: 0
>>>> ....... : IO APIC version: 0011
>>>> .... register #02: 00000000
>>>> ....... : arbitration: 00
>>>> .... IRQ redirection table:
>>>> NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
>>>> ...
>>>> 14 09 1 1 0 1 0 0 0 59
>>>> ...
>>>>
>>>> ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
>>>> do_IRQ: cannot handle IRQ -1 vector 0x59 cpu 0
>>>> ------------[ cut here ]------------
>>>> Kernel BUG at 40206b11 [verbose debug info unavailable]
>>>> invalid opcode: 0000 [#1] SMP
>>>> Modules linked in:
>>>>
>>>> Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty
>> #23)
>>>> EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
>>>> EIP is at do_IRQ+0x6b/0xae
>>>> EAX: 00000032 EBX: 00001d28 ECX: 00003434 EDX: 00000046
>>>> ESI: 00000000 EDI: 00000059 EBP: c7a37d3c ESP: c7a37d14
>>>> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
>>>> Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)
>>>> Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff
>> c421bd20
>>>> c7a37d9c c7a37dac c7a37d7c 4020555f c421bd20 00000000 c421bd20 c7a37d9c
>>>> c7a37dac c7a37d7c 40b717f8 0000007b 0000007b 000000d8 ffffffa6 4080db6c
>>>> Call Trace:
>>>> [<4020555f>] ? common_interrupt+0x23/0x28
>>>>
>>>>
>>>> it is on 16cores system with 32bit bigsmp, so it is using phy_flat
>>>> cpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)
>>>>
>>>> but io_apic controller deliver that interrupt to cpu0 (with apicid =
>>>> 4) instead of cpu 5 (with apic id = 9)
>>>>
>>>> look at the 64 bit, TARGET_CPUS for phys_flat is cpu_online_map
>>>>
>>>> and 32bit bigsmp TARGET_CPUS is only one cpu set and rotating with online
>> cpu...
>>>>
>>>> Change 32bit bigsmp TARGE_CPUS ?
>>>
>>> Set vector_allocation_domain to CPU_MASK_ALL on 32bit. That doesn't give us
>>> the benefit of per cpu vectors right now, but in my research there has not
>>> been a 32bit kernel yet that has needed it. We have never shared vectors
>>> between 2 gsi on 32bit x86, we have only collapsed the irq space.
>>
>> TARGET_CPUS only used by ioapic_xx.c
>
> Target cpus is a hint to tell us what to do if the user has not.
>
>> vector_allocator_domain will return cpumask_of_cpu(cpu)..
>
> Which is a bug for lowest priority delivery mode. But you said
> phys_flat and not flat. Which sounds like bigsmp last I read it.
>
>>> On x86_64 before I did the per cpu vectors there were machines that
>>> combined multiple interrupt sources (gsi) into the same irq. So
>>> x86_64 has needed the per cpu vectors.
>>>
>>> Which means in practice that the irq compression on x86_32 was just a hack to
>>> with not having enough irq_desc entries. I wish I had realized that last
>>> time we were talking, as we could have unilaterally ripped out all of that
>>> code as completely unnecessary on x86 and just bumped NR_IRQS to 1024 on
>>> the boxes that had more than 256 gsis.
>>
>> now 32bit and 64bit is the same page now... (bigsmp == phys_flat)...
>>
>> will continue to merge io_apic_xx.c
>
> Hmm. In that case I will ask that you look at all of the pieces of
> irq migration code, and make certain that they have all come from x86_64.
yes, done. now it is same as 64 bit.
YH
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-15 1:41 ` Yinghai Lu
@ 2008-08-15 2:33 ` Eric W. Biederman
0 siblings, 0 replies; 25+ messages in thread
From: Eric W. Biederman @ 2008-08-15 2:33 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, linux-kernel,
Alan Cox, Andrew Morton
"Yinghai Lu" <yhlu.kernel@gmail.com> writes:
> yes, done. now it is same as 64 bit.
Cool. I'm now off until monday. Hopefully I can post some patches and we can
have a good debate then.
Eric
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-15 0:49 ` Yinghai Lu
2008-08-15 1:01 ` Eric W. Biederman
@ 2008-08-15 1:09 ` Eric W. Biederman
1 sibling, 0 replies; 25+ messages in thread
From: Eric W. Biederman @ 2008-08-15 1:09 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, linux-kernel,
Alan Cox, Andrew Morton
"Yinghai Lu" <yhlu.kernel@gmail.com> writes:
> On Thu, Aug 14, 2008 at 5:11 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>>
>>> find something interesting:
>>>
>>> found new irq_cfg for irq 20
>>> 0 add_pin_to_irq: irq 20 --> apic 0 pin 20
>>> assign_irq_vector: irq 20 vector 0x59 cpu 5
>>> IOAPIC[0]: Set routing entry (0-20 -> 0x59 -> IRQ 20 Mode:1 Active:1)
>>> found new irq_desc for irq 20
>>> pci 0000:00:02.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20
>>>
>>> IO APIC #0......
>>> .... register #00: 00000000
>>> ....... : physical APIC id: 00
>>> ....... : Delivery Type: 0
>>> ....... : LTS : 0
>>> .... register #01: 00170011
>>> ....... : max redirection entries: 0017
>>> ....... : PRQ implemented: 0
>>> ....... : IO APIC version: 0011
>>> .... register #02: 00000000
>>> ....... : arbitration: 00
>>> .... IRQ redirection table:
>>> NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:
>>> ...
>>> 14 09 1 1 0 1 0 0 0 59
>>> ...
>>>
>>> ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
>>> do_IRQ: cannot handle IRQ -1 vector 0x59 cpu 0
>>> ------------[ cut here ]------------
>>> Kernel BUG at 40206b11 [verbose debug info unavailable]
>>> invalid opcode: 0000 [#1] SMP
>>> Modules linked in:
>>>
>>> Pid: 70, comm: kasyncinit Not tainted (2.6.27-rc3-tip-00191-g98ccb89-dirty
> #23)
>>> EIP: 0060:[<40206b11>] EFLAGS: 00010092 CPU: 0
>>> EIP is at do_IRQ+0x6b/0xae
>>> EAX: 00000032 EBX: 00001d28 ECX: 00003434 EDX: 00000046
>>> ESI: 00000000 EDI: 00000059 EBP: c7a37d3c ESP: c7a37d14
>>> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
>>> Process kasyncinit (pid: 70, ti=c7a36000 task=c79c9860 task.ti=c7a36000)
>>> Stack: 40a74317 40814ea0 ffffffff 00000059 00000000 00000000 ffffffff
> c421bd20
>>> c7a37d9c c7a37dac c7a37d7c 4020555f c421bd20 00000000 c421bd20 c7a37d9c
>>> c7a37dac c7a37d7c 40b717f8 0000007b 0000007b 000000d8 ffffffa6 4080db6c
>>> Call Trace:
>>> [<4020555f>] ? common_interrupt+0x23/0x28
>>>
>>>
>>> it is on 16cores system with 32bit bigsmp, so it is using phy_flat
>>> cpu 5 has apicid 9, and ioapic reg setting right with Dmod= 0 ( phys)
>>>
>>> but io_apic controller deliver that interrupt to cpu0 (with apicid =
>>> 4) instead of cpu 5 (with apic id = 9)
>>>
>>> look at the 64 bit, TARGET_CPUS for phys_flat is cpu_online_map
>>>
>>> and 32bit bigsmp TARGET_CPUS is only one cpu set and rotating with online
> cpu...
>>>
>>> Change 32bit bigsmp TARGE_CPUS ?
>>
>> Set vector_allocation_domain to CPU_MASK_ALL on 32bit. That doesn't give us
>> the benefit of per cpu vectors right now, but in my research there has not
>> been a 32bit kernel yet that has needed it. We have never shared vectors
>> between 2 gsi on 32bit x86, we have only collapsed the irq space.
>
> TARGET_CPUS only used by ioapic_xx.c
>
> vector_allocator_domain will return cpumask_of_cpu(cpu)..
Note: Only vector_allocation_domain matters. That is where
we setup the irq to be received. TARGET_CPUS is just a request
to send the irq to someplace in that mask.
Eric
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-14 20:42 ` Yinghai Lu
2008-08-14 21:24 ` Yinghai Lu
@ 2008-08-14 23:55 ` Eric W. Biederman
1 sibling, 0 replies; 25+ messages in thread
From: Eric W. Biederman @ 2008-08-14 23:55 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, linux-kernel,
Alan Cox, Andrew Morton
"Yinghai Lu" <yhlu.kernel@gmail.com> writes:
> On Thu, Aug 14, 2008 at 1:05 PM, Eric W. Biederman
>> What I wound up using in my tree is a little different.
>>
>> I introduced an opaque/empty structure: struct irq to be used in places
>> where we need pointers instead of an integer irq number in the interfaces.
>>
>> I have a version of the genirq api that works on struct irq instead of
>> unsigned int irq.
>>
>> I have functions:
>> struct irq * to_irq(unsigned int nr);
>> struct irq_desc *to_idesc(struct irq *);
>> unsigned int irq_nr(struct irq *irq);
>
> struct irq {
> unsigned int nr;
> struct irq_desc *idesc;
> }
I did:
struct irq_desc {
struct irq irq;
....
}
Then to_idesc is just a container_of call. Or simply a type cast but
that is rude.
Having nr be a field in struct irq is possibly valid.
When last we talked about the design Linus was emphatic that what gets
exposed to drivers be an opaque token. When I looked for 99%+ of the
arch code we can use that same opaque token. irq_desc is something
we don't really care about except in do_IRQ().
So I guess the truly important thing is that struct irq is not
ultimately available in a usable form to drivers.
We seem to give drivers access to everything when they include interrupt.h
So I'm not certain how strict we can succeed in being still is a good goal
to aim for.
>> Is there any reason why the migration path for architectures can not be:
>> Until they are converted:
>> #define NR_IRQS and use the irq_desc array.
>>
>> If they are just using a dynamically allocated array.
>> #define NR_IRQS nr_irqs
>>
>> Once we kill the array entirely.
>> #undef NR_IRQS or
>> #define NR_IRQS 0xfffff000
> why not use -1U here?
So that negative error codes continue not to be valid irqs.
In most places irq is an unsigned int so it may safely be used to index irq_desc.
In other paces people are sloppier and used a signed value so they can return
negative error values. create_irq() on x86 is one of those places. There
is also platform_get_irq. and possibly a few others.
Eric
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-14 19:01 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Yinghai Lu
2008-08-14 20:05 ` Eric W. Biederman
@ 2008-08-15 12:18 ` Ingo Molnar
1 sibling, 0 replies; 25+ messages in thread
From: Ingo Molnar @ 2008-08-15 12:18 UTC (permalink / raw)
To: Yinghai Lu
Cc: Thomas Gleixner, H. Peter Anvin, linux-kernel, Alan Cox,
Eric W. Biederman, Andrew Morton
* Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> > A couple of observations about the general structure of the sparse irqs
> > code:
> >
> > - the new APIs should probably live in mm/bootmem.c not in init/main.c,
> > and in bootmem.h. Also, it should be outlined clearly why this new API
> > is needed as a wrapper ontop of existing bootmem mechanisms.
>
> move
> pre_alloc_dyn_array, per_cpu_dyn_array_size, per_cpu_alloc_dyn_array
> to mm/bootmem.c?
yeah, i think so. It's an "even earlier than bootmem" bootmem allocator.
> > - the #ifdef complications, while fine for migration, should be
> > eliminated. Could we introduce some compatible form for the
> > definition/allocation APIs that work even if an architecture still
> > uses a flat irq array? That would remove most of the uglinesses.
> # git grep CONFIG_HAVE_DYN_ARRAY | wc -l
> 9
>
> #git grep CONFIG_HAVE_SPARSE_IRQ | wc -l
> 39
>
> arch/x86/kernel/io_apic_32.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
> arch/x86/kernel/io_apic_32.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> arch/x86/kernel/io_apic_64.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
> arch/x86/kernel/io_apic_64.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> arch/x86/kernel/irq_32.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> arch/x86/kernel/irq_64.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> drivers/char/random.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> drivers/char/random.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> drivers/pci/intr_remapping.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> drivers/pci/intr_remapping.c:#else /* !CONFIG_HAVE_SPARSE_IRQ */
> drivers/pci/intr_remapping.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> fs/proc/proc_misc.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
> include/linux/irq.h:#ifdef CONFIG_HAVE_SPARSE_IRQ
> include/linux/irq.h:#if defined(CONFIG_INTR_REMAP) &&
> defined(CONFIG_HAVE_SPARSE_IRQ)
> include/linux/irq.h:#ifndef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/chip.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ_DEBUG
> kernel/irq/handle.c:#ifndef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/handle.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/manage.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/manage.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
> kernel/irq/migration.c:#ifdef CONFIG_HAVE_SPARSE_IRQ
>
> because try to avoid more api to be changed to take irq_desc as parameter.
yes - but in the end we should remove all the #ifdefs and try to hide
them away into include file driven abstractions.
> > - some of the irq < 16 checks in x86 look a bit ugly, can we do anything
> > about them?
>
> is_legacy_irq(irq) ? or legacy_irq(irq)?
legacy_irq(irq) sounds like the right name to me.
> > - i think as a final-ish commit we should just remove the dyn-array
> > define and make all architectures use this facility. You converted
> > most of them - how many are still missing? Sparse-irq is more
> > intrusive so that should probably stay a Kconfig knob.
>
> so when config_sparse_irq is not selected, need to use dyn_array to
> allocate irq_desc and irq_cfg, or just static array?
well in the worst case just static array - but lets use the same APIs on
them in .c files.
i.e. we can make this all gradual and compatible - and we can allow dual
use of old-style irq_desc[] _and_ the new APIs in the same kernel even
(so that old architectures will work just fine, even if not touched) -
but he tons of #ifdefs are ugly.
> > - there was one aspect of NR_IRQS that was nice and useful: it acted as
> > a sanity check against BIOS bugs and driver bugs that pass in some
> > irrealistically high irq number. Now we'll just try to allocate some
> > really high IRQ and accept it. I _think_ there should be a single,
> > simple 'absolute maximum IRQ number' define which should set the
> > maximum possible IRQ number. Lets call it NR_IRQS_MAX or so, and set
> > it to NR_CPUS*NR_IO_APICS*224 or so?
>
> when sparse_irq is used, irq is [0, -1U]
> driver could be irq_desc(irq) to check if irq is valid or not. and use
> irq_desc_with_new(new) to get a new one.
ok. The suggestion from Eric is still valid, to use 0xffff0000, to
exclude small negative numbers. (so that a driver does not accidentally
pass a -EINVAL or -ENODEV into request_irq() or so)
> when generic_hardirqs is not used (s390, m68k, sparc), we need to
> create some stubs in linux/interrupt.h for them
ok.
> > - i'm a bit worried about linecount increase in general:
> >
> > 247 files changed, 3671 insertions(+), 2052 deletions(-)
> >
> > could we work on reducing that somewhat? The new infrastructure bits
> > in mm/* and kernel/irq/* will be unavoidable, what we should
> > concentrate on is to make usage of the new facility just as
> > straightforward, easy and compact as the old irq_desc[] usages.
>
> before that we could use get_irq_desc() and get_irq_desc_without_new()
> and according to eric, i changed that to irq_desc_with_new and
> irq_desc().
>
> so the array irq_desc[] need to be changed to irq_descX[] ( or
> *irq_desc to *irq_descX for dyn_array)
>
> >
> > A worst-case example is drivers/char/random.c: the
> > CONFIG_HAVE_SPARSE_IRQ and CONFIG_HAVE_DYN_ARRAY #ifdef jungle is not
> > acceptable. I think the best way out is to convert the whole kernel to
> > the new facilities (as safely as possible, without breaking other
> > architectures), and making sure that the end result is easy to
> > understand and intuitive.
>
> # grep CONFIG_HAVE_ drivers/char/random.c
> #ifndef CONFIG_HAVE_SPARSE_IRQ
> #ifdef CONFIG_HAVE_DYN_ARRAY
> #ifndef CONFIG_HAVE_SPARSE_IRQ
>
> just want to make other arch is untouched.
that should still be the case - untouched architectures should continue
to work - but cannot we just wrap it all for them so that the new APIs
will simply access the static, non-sparse irq_desc[] array that those
old architectures presume exist?
Ingo
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-14 13:26 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Ingo Molnar
` (5 preceding siblings ...)
2008-08-14 19:01 ` [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10 Yinghai Lu
@ 2008-08-29 21:16 ` Andrew Morton
2008-08-29 21:43 ` Yinghai Lu
6 siblings, 1 reply; 25+ messages in thread
From: Andrew Morton @ 2008-08-29 21:16 UTC (permalink / raw)
To: Ingo Molnar; +Cc: yhlu.kernel, tglx, hpa, linux-kernel, alan, ebiederm
On Thu, 14 Aug 2008 15:26:38 +0200
Ingo Molnar <mingo@elte.hu> wrote:
> ok, i've created a new tip/irq/sparseirq topic branch for this.
This:
init/dyn_array.c: In function 'pre_alloc_dyn_array':
init/dyn_array.c:21: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
init/dyn_array.c:45: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
init/dyn_array.c: In function 'per_cpu_dyn_array_size':
init/dyn_array.c:78: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
init/dyn_array.c: In function 'per_cpu_alloc_dyn_array':
init/dyn_array.c:107: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
is reminding us about %pS/%pF.
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-29 21:16 ` Andrew Morton
@ 2008-08-29 21:43 ` Yinghai Lu
2008-08-29 21:49 ` Andrew Morton
0 siblings, 1 reply; 25+ messages in thread
From: Yinghai Lu @ 2008-08-29 21:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ingo Molnar, tglx, hpa, linux-kernel, alan, ebiederm
On Fri, Aug 29, 2008 at 2:16 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu, 14 Aug 2008 15:26:38 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
>> ok, i've created a new tip/irq/sparseirq topic branch for this.
>
> This:
>
> init/dyn_array.c: In function 'pre_alloc_dyn_array':
> init/dyn_array.c:21: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
> init/dyn_array.c:45: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
> init/dyn_array.c: In function 'per_cpu_dyn_array_size':
> init/dyn_array.c:78: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
> init/dyn_array.c: In function 'per_cpu_alloc_dyn_array':
> init/dyn_array.c:107: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
>
> is reminding us about %pS/%pF.
in init/main.c::do_one_initcall() is still using it...
also i didn't get this warning, what is your gcc version?
YH
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-29 21:43 ` Yinghai Lu
@ 2008-08-29 21:49 ` Andrew Morton
2008-08-29 21:54 ` Yinghai Lu
0 siblings, 1 reply; 25+ messages in thread
From: Andrew Morton @ 2008-08-29 21:49 UTC (permalink / raw)
To: Yinghai Lu; +Cc: mingo, tglx, hpa, linux-kernel, alan, ebiederm
On Fri, 29 Aug 2008 14:43:45 -0700
"Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
> On Fri, Aug 29, 2008 at 2:16 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Thu, 14 Aug 2008 15:26:38 +0200
> > Ingo Molnar <mingo@elte.hu> wrote:
> >
> >> ok, i've created a new tip/irq/sparseirq topic branch for this.
> >
> > This:
> >
> > init/dyn_array.c: In function 'pre_alloc_dyn_array':
> > init/dyn_array.c:21: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
> > init/dyn_array.c:45: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
> > init/dyn_array.c: In function 'per_cpu_dyn_array_size':
> > init/dyn_array.c:78: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
> > init/dyn_array.c: In function 'per_cpu_alloc_dyn_array':
> > init/dyn_array.c:107: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
> >
> > is reminding us about %pS/%pF.
>
> in init/main.c::do_one_initcall() is still using it...
So?
That got converted in -mm.
> also i didn't get this warning, what is your gcc version?
See http://userweb.kernel.org/~akpm/mmotm/broken-out/vsprintf-use-new-vsprintf-symbolic-function-pointer-format.patch
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 00/53] dyn_array/nr_irqs/sparse_irq support v10
2008-08-29 21:49 ` Andrew Morton
@ 2008-08-29 21:54 ` Yinghai Lu
0 siblings, 0 replies; 25+ messages in thread
From: Yinghai Lu @ 2008-08-29 21:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: mingo, tglx, hpa, linux-kernel, alan, ebiederm
On Fri, Aug 29, 2008 at 2:49 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Fri, 29 Aug 2008 14:43:45 -0700
> "Yinghai Lu" <yhlu.kernel@gmail.com> wrote:
>
>> On Fri, Aug 29, 2008 at 2:16 PM, Andrew Morton
>> <akpm@linux-foundation.org> wrote:
>> > On Thu, 14 Aug 2008 15:26:38 +0200
>> > Ingo Molnar <mingo@elte.hu> wrote:
>> >
>> >> ok, i've created a new tip/irq/sparseirq topic branch for this.
>> >
>> > This:
>> >
>> > init/dyn_array.c: In function 'pre_alloc_dyn_array':
>> > init/dyn_array.c:21: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
>> > init/dyn_array.c:45: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
>> > init/dyn_array.c: In function 'per_cpu_dyn_array_size':
>> > init/dyn_array.c:78: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
>> > init/dyn_array.c: In function 'per_cpu_alloc_dyn_array':
>> > init/dyn_array.c:107: warning: 'print_fn_descriptor_symbol' is deprecated (declared at include/linux/kallsyms.h:100)
>> >
>> > is reminding us about %pS/%pF.
>>
>> in init/main.c::do_one_initcall() is still using it...
>
> So?
>
> That got converted in -mm.
>
>> also i didn't get this warning, what is your gcc version?
>
> See http://userweb.kernel.org/~akpm/mmotm/broken-out/vsprintf-use-new-vsprintf-symbolic-function-pointer-format.patch
thanks
will send one patch to you
YH
^ permalink raw reply [flat|nested] 25+ messages in thread