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: <d760cf2d0903181930m782932a4reda3a0b582489f5d@mail.gmail.com>
Date:	Thu, 19 Mar 2009 08:00:17 +0530
From:	Nitin Gupta <ngupta@...are.org>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3]: xvmalloc memory allocator

On Thu, Mar 19, 2009 at 12:51 AM, Pekka Enberg <penberg@...helsinki.fi> wrote:
> 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.
>

I can see quite some places for cleanups (like macros for
reaching next free block etc). Do you think CamelCase will be acceptable
for now? and also keeping xvmalloc name? Other than these, I will
check for potential cleanups and send updated diffs.

Thanks,
Nitin
--
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/