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: <20110302163729.GQ3319@htj.dyndns.org>
Date:	Wed, 2 Mar 2011 17:37:29 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	David Rientjes <rientjes@...gle.com>, 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

Hey, Yinghai.

On Wed, Mar 02, 2011 at 08:16:18AM -0800, Yinghai Lu wrote:
> my original part:
> 
> @@ -393,7 +393,7 @@ void __init numa_reset_distance(void)
>         size_t size;
>  
>         if (numa_distance_cnt) {
> -               size = numa_distance_cnt * sizeof(numa_distance[0]);
> +               size = numa_distance_cnt * numa_distance_cnt * sizeof(numa_distance[0]);
>                 memblock_x86_free_range(__pa(numa_distance),
>                                         __pa(numa_distance) + size);
>                 numa_distance_cnt = 0;
> 
> So can you tell me why you need to make those change?
> 	move out assigning or numa_distance_cnt and size of the the IF

Please read the patch description.  I actually wrote that down.  :-)

> the change include:
> 1. you only need to go over new_nr*new_nr instead huge MAX_NUMNODES * MAX_NUMNODES
> 2. you do NOT need to go over it if you don't have phys_dist assigned before.
>    numa_alloc_distance already have that default set.
> 3. do need to check if phys_dist is assigned before referring phys_dist.

* If you wanted to make that change, split it into a separate patch.
  Don't mix it with changes which actually fix the bug.

* I don't think it's gonna matter all that much.  It's one time and
  only used if emulation is enabled, but then again yeap MAX_NUMNODES
  * MAX_NUMNODES can get quite high, but it looks way too complicated
  for what it achieves.  Just looping over enabled nodes should
  achieve about the same thing in much simpler way, right?

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