linux-kernel - Re: Regression in linux-next

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1710161452560.1973@nanos>
Date:   Mon, 16 Oct 2017 14:54:16 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Petri Latvala <petri.latvala@...el.com>
cc:     Yu Chen <yu.c.chen@...el.com>, Juergen Gross <jgross@...e.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Tony Luck <tony.luck@...el.com>,
        Marc Zyngier <marc.zyngier@....com>,
        Alok Kataria <akataria@...are.com>,
        Joerg Roedel <joro@...tes.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Steven Rostedt <rostedt@...dmis.org>,
        Christoph Hellwig <hch@....de>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Rui Zhang <rui.zhang@...el.com>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Len Brown <lenb@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Regression in linux-next

On Mon, 16 Oct 2017, Thomas Gleixner wrote:
> On Mon, 16 Oct 2017, Petri Latvala wrote:
> > > That should dump the trace buffer when the bug hits. I try to reproduce
> > > myself.
> > 
> > With those:
> > 
> > # rtcwake -s 15 -m mem
> > 
> > [   67.069522] kernel BUG at arch/x86/kernel/apic/vector.c:154!
> > [   67.075509] invalid opcode: 0000 [#1] PREEMPT SMP
> > [   67.080481] Dumping ftrace buffer:
> 
> Hrm. I completely forgot that this does not dump the buffers of offline
> CPUs. So half of the information is missing. So forget the tracer for now.
> 
> Can you please apply the debug patch below and provide the full dmesg
> output?
> 
> Its going to be too big for LKML so either upload it somewhere or send it
> to me in private mail.
> 
> Note, I removed the BUG_ON, so box might survive suspend/resume but it
> should trigger that printout.

Forgot to add the counterpart to the clear side. Updated patch below.

Thanks,

	tglx

8<----------------

--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -140,6 +140,10 @@ static void apic_update_vector(struct ir
 	trace_vector_update(irqd->irq, newvec, newcpu, apicd->vector,
 			    apicd->cpu);
 
+	pr_err("VU: CPU %u irq %u newvec %u newcpu %u curvec %u curcpu %u desc %p\n",
+	       smp_processor_id(),irqd->irq, newvec, newcpu, apicd->vector,
+	       apicd->cpu, desc);
+
 	/* Setup the vector move, if required  */
 	if (apicd->vector && cpu_online(apicd->cpu)) {
 		apicd->move_in_progress = true;
@@ -151,7 +155,9 @@ static void apic_update_vector(struct ir
 
 	apicd->vector = newvec;
 	apicd->cpu = newcpu;
-	BUG_ON(!IS_ERR_OR_NULL(per_cpu(vector_irq, newcpu)[newvec]));
+	if (!IS_ERR_OR_NULL(per_cpu(vector_irq, newcpu)[newvec]))
+		pr_err("VU not empty %p\n", per_cpu(vector_irq, newcpu)[newvec]);
+
 	per_cpu(vector_irq, newcpu)[newvec] = desc;
 }
 
@@ -316,6 +322,10 @@ static void clear_irq_vector(struct irq_
 
 	lockdep_assert_held(&vector_lock);
 
+	pr_err("VC: CPU %u irq %u curvec %u curcpu %u oldvec %u oldcpu %u\n",
+	       smp_processor_id(),irqd->irq, apicd->vector, apicd->cpu,
+	       apicd->prev_vector, apicd->prev_cpu);
+
 	if (!vector)
 		return;