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:	Thu, 21 Apr 2011 16:49:26 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Christoph Lameter <cl@...ux.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Pekka Enberg <penberg@...nel.org>,
	Michal Hocko <mhocko@...e.cz>, Hugh Dickins <hughd@...gle.com>,
	linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>,
	linux-parisc@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	x86 maintainers <x86@...nel.org>
Subject: Re: [PATCH v3] mm: make expand_downwards symmetrical to
 expand_upwards

On Thu, 2011-04-21 at 14:34 -0700, David Rientjes wrote:
> On Thu, 21 Apr 2011, James Bottomley wrote:
> 
> > >  - parisc: James has already queued "parisc: set memory ranges in 
> > >    N_NORMAL_MEMORY when onlined" for 2.6.39, so all he needs now is 
> > >    to merge a hybrid of the Kconfig changes requiring CONFIG_NUMA for 
> > >    CONFIG_DISCONTIGMEM from KOSAKI-san and myself which also fix the 
> > >    compile issues,
> > 
> > Not quite: if we go this route, we need to sort out our CPU scheduling
> > problem as well ... as I said, I don't think we've got all the necessary
> > numa machinery in place yet.
> > 
> 
> Ok, it seems like there're two options for this release cycle:
> 
>  (1) merge the patch that enables CONFIG_NUMA for DISCONTIGMEM but only 
>      do so if CONFIG_SLUB is enabled to avoid the build error, or

That's not an option without coming up with the rest of the numa
fixes ... we can't basically force all SMP systems to become UP.

What build error, by the way?  There's only a runtime panic caused by
slub.

>  (2) disallow CONFIG_SLUB for parisc with DISCONTIGMEM.

Well, that's this patch ... it will actually fix every architecture, not
just parisc.


> diff --git a/init/Kconfig b/init/Kconfig
> index 56240e7..a7ad8fb 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1226,6 +1226,7 @@ config SLAB
>           per cpu and per node queues.
>  
>  config SLUB
> +       depends on BROKEN || NUMA || !DISCONTIGMEM
>         bool "SLUB (Unqueued Allocator)"
>         help
>            SLUB is a slab allocator that minimizes cache line usage


I already sent it to linux-arch and there's been no dissent; there have
been a few "will that fix my slub bug?" type of responses.

James


--
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