linux-kernel - Re: [PATCH v7 0/5] Make cpuid <-> nodeid mapping persistent

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: <CAJZ5v0hWdmQO_KukE7ewsPSWsYMi8K2B0rs0vRtE1t9jU=pWAQ@mail.gmail.com>
Date:	Thu, 19 May 2016 14:58:54 +0200
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Zhu Guihua <zhugh.fnst@...fujitsu.com>
Cc:	cl@...ux.com, Tejun Heo <tj@...nel.org>, mika.j.penttila@...il.com,
	Ingo Molnar <mingo@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"H. Peter Anvin" <hpa@...or.com>, yasu.isimatu@...il.com,
	isimatu.yasuaki@...fujitsu.com, kamezawa.hiroyu@...fujitsu.com,
	izumi.taku@...fujitsu.com, gongzhaogang@...pur.com,
	Len Brown <len.brown@...el.com>, Len Brown <lenb@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>, chen.tang@...ystack.cn,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: [PATCH v7 0/5] Make cpuid <-> nodeid mapping persistent

On Thu, May 19, 2016 at 12:41 PM, Zhu Guihua <zhugh.fnst@...fujitsu.com> wrote:
> Hi Rafael,

Hi,

> This patch set was reported a kernel panic from Intel LKP team.
> I do some investigation for this. I found that this panic was caused
> because of Intel test machine. On their machine, the acpi tables has
> something wrong. The proc_id of processors which are not present
> cannot be assigned correctly, they are assigned the same value.
> The wrong value will be used by our patch, and lead to panic.

Well, if there's a system that works before your patch and doesn't
work after it, the patch has to be modified to let the system still
work.

Maybe you can detect the firmware defect in question and work around
it so as to avoid the panic?