2006-11-12 17:48:22

by Adrian Bunk

[permalink] [raw]
Subject: [2.6 patch] arch/i386/kernel/io_apic.c: handle a negative return value

The Coverity checker noted that bad things might happen if
find_isa_irq_apic() returned -1.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6/arch/i386/kernel/io_apic.c.old 2006-11-12 18:41:24.000000000 +0100
+++ linux-2.6/arch/i386/kernel/io_apic.c 2006-11-12 18:42:00.000000000 +0100
@@ -2160,7 +2160,8 @@ static inline void unlock_ExtINT_logic(v

pin = find_isa_irq_pin(8, mp_INT);
apic = find_isa_irq_apic(8, mp_INT);
- if (pin == -1)
+
+ if ((pin == -1) || (apic == -1))
return;

entry0 = ioapic_read_entry(apic, pin);


2006-11-13 08:10:22

by Ingo Molnar

[permalink] [raw]
Subject: Re: [2.6 patch] arch/i386/kernel/io_apic.c: handle a negative return value

On Sun, 2006-11-12 at 18:48 +0100, Adrian Bunk wrote:
> The Coverity checker noted that bad things might happen if
> find_isa_irq_apic() returned -1.
>
> Signed-off-by: Adrian Bunk <[email protected]>

hm, it seems the checker did not notice the following:
find_isa_irq_apic() can return -1 /only/ if find_isa_irq_pin() returns
-1 too. So this is not a bug - it's rather a bit unclean code (and
adding a check for -1 apic does not make the code cleaner).

Ingo

2006-11-14 00:46:41

by Andrew Morton

[permalink] [raw]
Subject: Re: [2.6 patch] arch/i386/kernel/io_apic.c: handle a negative return value

On Sun, 12 Nov 2006 18:48:26 +0100
Adrian Bunk <[email protected]> wrote:

> The Coverity checker noted that bad things might happen if
> find_isa_irq_apic() returned -1.
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
> --- linux-2.6/arch/i386/kernel/io_apic.c.old 2006-11-12 18:41:24.000000000 +0100
> +++ linux-2.6/arch/i386/kernel/io_apic.c 2006-11-12 18:42:00.000000000 +0100
> @@ -2160,7 +2160,8 @@ static inline void unlock_ExtINT_logic(v
>
> pin = find_isa_irq_pin(8, mp_INT);
> apic = find_isa_irq_apic(8, mp_INT);
> - if (pin == -1)
> +
> + if ((pin == -1) || (apic == -1))
> return;
>

I dunno about this. For some reason I don't trust the apic code much. At
present if find_isa_irq_apic() fails we at least have a chance of
blundering into a nnice oops or something. By adding correct
error-checking we increase the chance of things just silently not working.

So let's see what this does...




From: Adrian Bunk <[email protected]>

The Coverity checker noted that bad things might happen if
find_isa_irq_apic() returned -1.

Signed-off-by: Adrian Bunk <[email protected]>
Cc: Andi Kleen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---

arch/i386/kernel/io_apic.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletion(-)

diff -puN arch/i386/kernel/io_apic.c~arch-i386-kernel-io_apicc-handle-a-negative-return-value arch/i386/kernel/io_apic.c
--- a/arch/i386/kernel/io_apic.c~arch-i386-kernel-io_apicc-handle-a-negative-return-value
+++ a/arch/i386/kernel/io_apic.c
@@ -2166,9 +2166,17 @@ static inline void unlock_ExtINT_logic(v
unsigned char save_control, save_freq_select;

pin = find_isa_irq_pin(8, mp_INT);
+ if (pin == -1) {
+ printk(KERN_ERR "unlock_ExtINT_logic: find_isa_irq_pin()
+ "failed\n");
+ return;
+ }
apic = find_isa_irq_apic(8, mp_INT);
- if (pin == -1)
+ if (apic == -1) {
+ printk(KERN_ERR "unlock_ExtINT_logic: find_isa_irq_apic()
+ "failed\n");
return;
+ }

entry0 = ioapic_read_entry(apic, pin);
clear_IO_APIC_pin(apic, pin);
_



2006-11-14 06:48:58

by Ingo Molnar

[permalink] [raw]
Subject: Re: [2.6 patch] arch/i386/kernel/io_apic.c: handle a negative return value

On Mon, 2006-11-13 at 16:42 -0800, Andrew Morton wrote:
> pin = find_isa_irq_pin(8, mp_INT);
> + if (pin == -1) {
> + printk(KERN_ERR "unlock_ExtINT_logic:
> find_isa_irq_pin()
> + "failed\n");
> + return;
> + }
> apic = find_isa_irq_apic(8, mp_INT);
> - if (pin == -1)
> + if (apic == -1) {
> + printk(KERN_ERR "unlock_ExtINT_logic:
> find_isa_irq_apic()
> + "failed\n");
> return;
> + }

as i mentioned it in my mail yesterday, if find_isa_irq_apic() returns
-1 then find_isa_irq_pin() has to return -1 too. But this is obscure and
needs to be documented at least - and your patch is good for
documentation purposes too :-)

Acked-by: Ingo Molnar <[email protected]>

Ingo