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]
Date:	Thu, 21 Jan 2010 16:33:36 +0800
From:	Haicheng Li <haicheng.li@...ux.intel.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	Ingo Molnar <mingo@...hat.com>, Yinghai Lu <yinghai@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org
Subject: Re: [patch] x86: set hotpluggable nodes in nodes_possible_map

David Rientjes wrote:
> On Thu, 21 Jan 2010, Haicheng Li wrote:
> 
>>> Nack, we don't need to add yet another nodemask because you're having
>>> trouble finding a new name for a cpu_nodes_parsed.  It would be perfectly 
>> Hey Dave, why do you think it's just a naming issue?
>>
>> What I'm concerning is that your assumption of cpu_nodes_parsed use is wrong,
>> cpu_nodes_parsed is needed anyway since its semantics represent the node with
>> cpu affinity rather than memless node, that's also why I originally doubted
>> cpu_node_parsed cannot handle hotplug node.
> 
> Wrong, cpu_nodes_parsed (despite its name) solely represents nodes that do 
> not have online address memory ranges.  That's it.  Nothing more, nothing 
> less.  That's why I suggest you rename it to no_mem_nodes or something 
> similar.  Look at the single time that the nodemask is used: to set 
> cleared bits in node_possible_map that were not set in nodes_parsed 
> because THEY DO NOT HAVE ASSOCIATED ONLINE MEMORY RANGES, the _only_ time 
> a node gets set in nodes_parsed.
> 
> Once you rename nodes_parsed to mem_nodes and cpu_nodes_parsed to 
> no_mem_nodes, it may become clearer.
> 
>> we also need hp_nodes_parsed to represent the node with hotpluggable memory
>> region, just like why we need nodes_parsed to repsent node with mem on.
>>
> 
> It's pointless to add another nodemask, the semantics of cpu_nodes_parsed 
> is perfectly legitimate for hotpluggable nodes as well.  Instead of 
> fixating on the name, look at the code that uses it.

I'm not meant to be rude, but it's illogical excuse. that it is now used by a single function 
doesn't mean that it will never be used by others in future or it is only useful for that single 
function.

see the code, we can find such relationships between related data-structures.
- struct bootnode nodes[] -> nodes_parsed
all the node in nodes_parsed should have a relative mem range in nodes[].

- apicid_to_node[] -> cpu_nodes_parsed
all the value of apicid_to_node[] should be valid in cpu_nodes_parsed. If we put hotpluggable node 
into cpu_nodes_parsed, such relationship is broken, right?

- nodes_add[] -> ?? (this is for hotpluggable node)
all the hotplugged mem can find a corresponding node thru nodes_add[].

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ