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: <20130618015806.GY32663@mtj.dyndns.org>
Date:	Mon, 17 Jun 2013 18:58:06 -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,
	David Rientjes <rientjes@...gle.com>
Subject: Re: [Part1 PATCH v5 16/22] x86, mm, numa: Move numa emulation
 handling down.

On Thu, Jun 13, 2013 at 09:03:03PM +0800, Tang Chen wrote:
> From: Yinghai Lu <yinghai@...nel.org>
> 
> numa_emulation() needs to allocate buffer for new numa_meminfo
> and distance matrix, so execute it later in x86_numa_init().
> 
> Also we change the behavoir:
> 	- before this patch, if user input wrong data in command
> 	  line, it will fall back to next numa probing or disabling
> 	  numa.
> 	- after this patch, if user input wrong data in command line,
> 	  it will stay with numa info probed from previous probing,
> 	  like ACPI SRAT or amd_numa.
> 
> We need to call numa_check_memblks to reject wrong user inputs early
> so that we can keep the original numa_meminfo not changed.

So, this is another very subtle ordering you're adding without any
comment and I'm not sure it even makes sense because the function can
fail after that point.

I'm getting really doubtful about this whole approach of carefully
splitting discovery and registration.  It's inherently fragile like
hell and the poor documentation makes it a lot worse.  I'm gonna reply
to the head message.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ