linux-kernel - Re: [PATCH 2/3]: xvmalloc memory allocator

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: <84144f020903181221t480caa5dhef0e581a7bef006@mail.gmail.com>
Date:	Wed, 18 Mar 2009 12:21:30 -0700
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Nitin Gupta <ngupta@...are.org>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3]: xvmalloc memory allocator

On Wed, 18 Mar 2009, Nitin Gupta wrote:
>>> > Slab memory is not backed by vmalloc space.
>>> Oh, it uses "low memory". Still not good for compcache :)

On Wed, Mar 18, 2009 at 10:28 PM, Christoph Lameter
<cl@...ux-foundation.org> wrote:
>> Only if you use 32 bit.

On Wed, Mar 18, 2009 at 10:29 AM, Nitin Gupta <ngupta@...are.org> wrote:
> Yes, this point is for 32-bit only - many users were unhappy with
> compcache size limit due to small vmalloc area on x86-32.

Yeah, I can see the point in having a custom allocator for this. But
quite frankly the xvmalloc code is just too ugly to live with. You
might want to make it look like kernel code as per CodingStyle and
change the name to something less generic.
--
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/