linux-kernel - Re: [Part1 PATCH v5 10/22] x86, mm, numa: Move two functions calling on successful path 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 17:53:11 -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 10/22] x86, mm, numa: Move two functions calling
 on successful path later

Hello,

Does the subject match the patch content?  What two functions?  The
patch is separating out the actual registration part so that the
discovery part can happen earlier, right?

> Currently, parsing numa info needs to allocate some buffer and need to be
> called after init_mem_mapping. So try to split parsing numa info procedure
> into two steps:
> 	- The first step will be called before init_mem_mapping, and it
> 	  should not need allocate buffers.

Document the requirement somewhere in the source code?

> 	- The second step will cantain all the buffer related code and be
> 	  executed later.
> 
> At last we will have early_initmem_init() and initmem_init().

Do you mean "eventually" or "in the end" by "at last"?

> This patch implements only the first step.
> 
> setup_node_data() and numa_init_array() are only called for successful
> path, so we can move these two callings to x86_numa_init(). That will also
> make numa_init() smaller and more readable.

I find the description somewhat difficult to follow.  :(

> -v2: remove online_node_map clear in numa_init(), as it is only
>      set in setup_node_data() at last in successful path.

I don't get this.  What prevents specific numa init functions (numaq,
x86_acpi, amd...) from updating node_online_map?

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/