linux-kernel - Re: [PATCH] init: call vfs_caches_init

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] [day] [month] [year] [list]

Message-ID: <20090602065534.GC31556@wotan.suse.de>
Date:	Tue, 2 Jun 2009 08:55:34 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	mingo@...e.hu, cl@...ux-foundation.com,
	torvalds@...ux-foundation.org, mpm@...enic.com, yinghai@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] init: call vfs_caches_init_early() later in the boot sequence

On Tue, Jun 02, 2009 at 09:48:32AM +0300, Pekka Enberg wrote:
> Hi Nick,
> 
> [ I see I typo'd Linus' email address in the original patch submission... ]
> 
> On Thu, May 28, 2009 at 04:29:25PM +0300, Pekka Enberg wrote:
> >> From: Pekka Enberg <penberg@...helsinki.fi>
> >>
> >> There's no need to call vfs_caches_init_early() before kmem_cache_init(). All
> >> we have to do is make sure we don't attempt to use the bootmem allocator after
> >> we've called mem_init().
> 
> On Mon, Jun 1, 2009 at 4:08 PM, Nick Piggin <npiggin@...e.de> wrote:
> > Hmm, but you'd want to be able to allocate > MAX_ORDER areas in the linear
> > KVA, which the page allocator cannot do. So this is just going to silently
> > truncate hash table size. Nack on this one.
> 
> OK, makes sense. IIRC, Linus suggested doing this but I think I'll
> just revert the patch.

What might be interesting to do is to be able to switch the bootmem
allocator to be able to run after the page allocator comes up (it
would have to have a few hooks to put pages on and off the buddy
lists, but should be possible). Then you could do these kinds of
large allocations later (or set up allocators earlier).

But that might not be worth the complexity and churn just for these
couple of cases...
--
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/