linux-kernel - Re: [Part1 PATCH v5 14/22] x86, mm, numa: Set memblock nid later

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:	Mon, 17 Jun 2013 18:45:18 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Tang Chen <tangchen@...fujitsu.com>
Cc:	tglx@...utronix.de, mingo@...e.hu, hpa@...or.com,
	akpm@...ux-foundation.org, trenn@...e.de, yinghai@...nel.org,
	jiang.liu@...wei.com, wency@...fujitsu.com, laijs@...fujitsu.com,
	isimatu.yasuaki@...fujitsu.com, mgorman@...e.de,
	minchan@...nel.org, mina86@...a86.com, gong.chen@...ux.intel.com,
	vasilis.liaskovitis@...fitbricks.com, lwoodman@...hat.com,
	riel@...hat.com, jweiner@...hat.com, prarit@...hat.com,
	x86@...nel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [Part1 PATCH v5 14/22] x86, mm, numa: Set memblock nid later

On Thu, Jun 13, 2013 at 09:03:01PM +0800, Tang Chen wrote:
> From: Yinghai Lu <yinghai@...nel.org>
> 
> In order to seperate parsing numa info procedure into two steps,

Short "why" would be nice.

> we need to set memblock nid later because it could change memblock
                                   ^
				   in where?

> array, and possible doube memblock.memory array which will allocate
             ^
	     possibly double

> buffer.

 which is bad why?

> Only set memblock nid once for successful path.
> 
> Also rename numa_register_memblks to numa_check_memblks() after
> moving out code of setting memblock nid.
> @@ -676,6 +669,11 @@ void __init x86_numa_init(void)
>  
>  	early_x86_numa_init();
>  
> +	for (i = 0; i < mi->nr_blks; i++) {
> +		struct numa_memblk *mb = &mi->blk[i];
> +		memblock_set_node(mb->start, mb->end - mb->start, mb->nid);
> +	}
> +

Can we please have some comments explaining the new ordering
requirements?  When reading code, how is one supposed to know that the
ordering of operations is all deliberate and fragile?

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/