linux-kernel - Re: [PATCH x86/mm UPDATED] x86-64, NUMA: Fix distance table handling

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 4 Mar 2011 15:32:56 +0100
From:	Tejun Heo <tj@...nel.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	tglx@...utronix.de, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH x86/mm UPDATED] x86-64, NUMA: Fix distance table
 handling

Hello,

On Thu, Mar 03, 2011 at 12:07:10PM -0800, David Rientjes wrote:
> The new emulation code needs to remove the assumption that node 0 always 
> is online and become more robust since there's no such restriction in the 
> ACPI spec.

Yeah, indeed, that's possible.  ACPI spec isn't really the deciding
factor here.  The node IDs are purely software and a system is
required to have at least one node, so it seems reasonable to require
node 0 to be always online - or even to require all online node IDs to
be consecutive starting from 0.  The only reason we may have holes in
node IDs now is because PXM -> nid mapping isn't released for empty
memory-only nodes.

The biggest downside of deferring checks for this type of rare
conditions to upper layers when not strictly necessary is that it
tends to lead to one-off bugs which trigger very infrequently.

That said, maybe we're already too deep toward that direction and it's
much easier to weed out the assumptions that node0 is always online.

Thanks.

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