linux-kernel - Re: Regression: kexec/kdump boot hangs with x86/vector commits

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: <20171213155746.GA29572@yu-chen.sh.intel.com>
Date:   Wed, 13 Dec 2017 23:57:46 +0800
From:   Yu Chen <yu.c.chen@...el.com>
To:     Dave Young <dyoung@...hat.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Juergen Gross <jgross@...e.com>,
        Tony Luck <tony.luck@...el.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Borislav Petkov <bp@...en8.de>,
        Rui Zhang <rui.zhang@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>, mingo@...nel.org,
        Yu Chen <yu.c.chen@...el.com>, kexec@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: Regression: kexec/kdump boot hangs with x86/vector commits

On Wed, Dec 13, 2017 at 10:52:56AM +0800, Dave Young wrote:
> Hi,
> 
> Kexec reboot and kdump has broken on my laptop for long time with
> 4.15.0-rc1+ kernels. With the patch below an early panic been fixed:
> https://patchwork.kernel.org/patch/10084289/
> 
> But still can not get a successful reboot, it looked like graphic
> issue, but after bisecting the kernel, I got below:
> 
> [dyoung@...p-*-* linux]$ git bisect good
> There are only 'skip'ped commits left to test.
> The first bad commit could be any of:
> 2db1f959d9dc16035f2eb44ed5fdb2789b754d6a
> 4900be83602b6be07366d3e69f756c1959f4169a
> We cannot bisect more!
> 
> These two commits can no be reverted because of code conflicts, thus
> I reverted the whole series from Thomas (below commits), with those
> x86/vector changes reverted, kexec reboot works fine.
> 
> Could you help to take a look, any thoughts?  I can do the test
> if you have some debug patch to try.
Is it possible that the "second" kernel runs on non-zero CPU? If yes,
what if some irqs are only delivered to cpu0? (use cpumask_of(0)
directly)

Thanks,
	Yu