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: <alpine.DEB.2.00.1002251315010.3501@chino.kir.corp.google.com>
Date:	Thu, 25 Feb 2010 13:45:42 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Andi Kleen <andi@...stfloor.org>,
	Nick Piggin <npiggin@...e.de>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, haicheng.li@...el.com,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [PATCH] [4/4] SLAB: Fix node add timer race in cache_reap

On Thu, 25 Feb 2010, Christoph Lameter wrote:

> > I don't see how memory hotadd with a new node being onlined could have
> > worked fine before since slab lacked any memory hotplug notifier until
> > Andi just added it.
> 
> AFAICR The cpu notifier took on that role in the past.
> 

The cpu notifier isn't involved if the firmware notifies the kernel that a 
new ACPI memory device has been added or you write a start address to 
/sys/devices/system/memory/probe.  Hot-added memory devices can include 
ACPI_SRAT_MEM_HOT_PLUGGABLE entries in the SRAT for x86 that assign them 
non-online node ids (although all such entries get their bits set in 
node_possible_map at boot), so a new pgdat may be allocated for the node's 
registered range.

Slab isn't concerned about that until the memory is onlined by doing 
echo online > /sys/devices/system/memory/memoryX/state for the new memory 
section.  This is where all the new pages are onlined, kswapd is started 
on the new node, and the zonelists are built.  It's also where the new 
node gets set in N_HIGH_MEMORY and, thus, it's possible to call 
kmalloc_node() in generic kernel code.  All that is done under 
MEM_GOING_ONLINE and not MEM_ONLINE, which is why I suggest the first and 
fourth patch in this series may not be necessary if we prevent setting the 
bit in the nodemask or building the zonelists until the slab nodelists are 
ready.
--
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