linux-kernel - Re: [BUG] tip tree - No irq handler for vector (irq -1)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 28 Jan 2010 22:51:27 -0800
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Jin Dongming <jin.dongming@...css.fujitsu.com>
Cc:	Li Zefan <lizf@...fujitsu.com>, Ingo Molnar <mingo@...e.hu>,
	Yinghai Lu <yinghai@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] tip tree - No irq handler for vector (irq -1)

On Thu, 2010-01-28 at 19:14 -0800, Jin Dongming wrote:
> Hi,
> 
> Maybe this problem is caused by that FIRST_DEVICE_VECTOR(IRQ 0x30)
> does not assigned really.

No. The problem is that this system's logical flat is behaving weird.

Even when the IO-APIC RTE says send the interrupt to cpu-0, it sends the
interrupt to cpu-1 (for which we haven't really initialized the vector
to irq mapping).

Actually this case is documented by Eric Biederman in the code like
this:

static void flat_vector_allocation_domain(int cpu, struct cpumask
*retmask)
{
        /* 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_clear(retmask);
        cpumask_bits(retmask)[0] = APIC_ALL_CPUS;
}

And the previous kernel codes were handling this and my recent changes
to vector assignments broke this behavior. My previous fix addressed a
portion of this issue and hence Zefan's keyboard etc started working.
Nevertheless there is one more corner case which needs to get addressed
and if my understanding is correct, the appended patch (ontop of the
patch that Zefan has already tested) should fix the issue.

Zefan, can you also apply this fix (untested/uncompiled) on top of the
previous fix and see if it resolves the issue? If so, I will add
appropriate changelog, comments and send it tomorrow morning for -tip
consideration after more testing. Thanks.
---

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 678d0b8..5d9896b 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -241,6 +241,13 @@ static void __cpuinit smp_callin(void)
 	map_cpu_to_logical_apicid();
 
 	notify_cpu_starting(cpuid);
+
+	/*
+ 	 * Need to setup vector mappings before we enable interrupts.
+ 	 */
+	lock_vector_lock();
+	__setup_vector_irq(smp_processor_id());
+	unlock_vector_lock();
 	/*
 	 * Get our bogomips.
 	 *
@@ -315,7 +322,6 @@ notrace static void __cpuinit start_secondary(void
*unused)
 	 */
 	ipi_call_lock();
 	lock_vector_lock();
-	__setup_vector_irq(smp_processor_id());
 	set_cpu_online(smp_processor_id(), true);
 	unlock_vector_lock();
 	ipi_call_unlock();


--
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/