[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D5C1322C3E673F459512FB59E0DDC32904F9EC8C@orsmsx414.amr.corp.intel.com>
Date: Mon, 28 Apr 2008 13:42:40 -0700
From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To: "Thomas Gleixner" <tglx@...utronix.de>
Cc: "Linus Torvalds" <torvalds@...ux-foundation.org>,
"LKML" <linux-kernel@...r.kernel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
<netdev@...r.kernel.org>
Subject: RE: [PATCH] ARCH: Fix 32-bit x86 MSI-X allocation leakage
> On Fri, 25 Apr 2008, PJ Waskiewicz wrote:
> > This bug was introduced in the 2.6.24 i386/x86_64 tree merge, where
>
> Can you please explain what exactly caused the bug.
> Definitely not the move from arch/i386 to arch/x86 as the
> code there was not changed at all and has not be changed since then.
>
> CC'ed Eric as well.
Eric replied with the actual commit during the 2.6.24 merge window that
introduced this bug. The io_apic.c code from the i386 tree did not stay
completely static when it was merged into the x86 io_apic_32.c code.
Here is the commit that Eric identified that introduced the defect:
In particular commit dbeb2be21d678c49a8d8bbf774903df15dd55474
Author: Rusty Russell <rusty@...tcorp.com.au>
Date: Fri Oct 19 20:35:03 2007 +0200
i386: introduce "used_vectors" bitmap which can be used to reserve
vectors.
This simplifies the io_apic.c __assign_irq_vector() logic and
removes
the explicit SYSCALL_VECTOR check, and also allows for vectors to be
reserved by other mechanisms (ie. lguest).
[ tglx: arch/x86 adaptation ]
Signed-off-by: Rusty Russell <rusty@...tcorp.com.au>
Signed-off-by: Andi Kleen <ak@...e.de>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Basically the code introduced the test_and_set_bit() on the used_vectors
bitmap, but it didn't have a corresponding clear_bit() on IRQ
destruction.
Cheers,
-PJ Waskiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists