linux-kernel - Re: [dm-devel] [PATCH 2/7] mm: introduce kvmalloc and kvmalloc

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: <559CD283.4020605@redhat.com>
Date:	Wed, 8 Jul 2015 09:34:27 +0200
From:	Zdenek Kabelac <zkabelac@...hat.com>
To:	device-mapper development <dm-devel@...hat.com>,
	Mikulas Patocka <mpatocka@...hat.com>
Cc:	Mike Snitzer <msnitzer@...hat.com>,
	Edward Thornber <thornber@...hat.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	"Alasdair G. Kergon" <agk@...hat.com>,
	David Rientjes <rientjes@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [dm-devel] [PATCH 2/7] mm: introduce kvmalloc and kvmalloc_node

Dne 7.7.2015 v 23:41 Andrew Morton napsal(a):
> On Tue, 7 Jul 2015 11:10:09 -0400 (EDT) Mikulas Patocka <mpatocka@...hat.com> wrote:
>
>> Introduce the functions kvmalloc and kvmalloc_node. These functions
>> provide reliable allocation of object of arbitrary size. They attempt to
>> do allocation with kmalloc and if it fails, use vmalloc. Memory allocated
>> with these functions should be freed with kvfree.
>
> Sigh.  We've resisted doing this because vmalloc() is somewhat of a bad
> thing, and we don't want to make it easy for people to do bad things.
>
> And vmalloc is bad because a) it's slow and b) it does GFP_KERNEL
> allocations for page tables and c) it is susceptible to arena
> fragmentation.
>
> We'd prefer that people fix their junk so it doesn't depend upon large
> contiguous allocations.  This isn't userspace - kernel space is hostile
> and kernel code should be robust.
>
> So I dunno.  Should we continue to make it a bit more awkward to use
> vmalloc()?  Probably that tactic isn't being very successful - people
> will just go ahead and open-code it.  And given the surprising amount
> of stuff you've placed in kvmalloc_node(), they'll implement it
> incorrectly...

Hi

 From my naive view:  4K-128K were nice restriction in the age of 16MB Pentium 
machines - but the time has changed and now users need to work with TB of memory.

So if the kernel driver is going to maintain such a huge chunk - it could 
hardly fit its resources into KB blocks.

So there are options - you could make complex code inside the driver to 
address every little kmalloc-ed chunk (and have a lot of potential for bugs) 
or you could always use vmalloc() and leave it on 'slow/GFP_KERNEL'.

So IMHO it's quite right to have the 'middle' road here - if there is enough 
memory to proceed with kmalloc - fine and if not - then driver will be 
somewhat slower but the coder will not have to spend months of coding 
reinvention of the wheel...

Personally I even find 128K pretty small if this limit comes from MB era and 
we are in the age of commonly available 32G laptops...

IMHO also it's kind of weird when kernel is not able to satisfy  128K 
allocation if there are gigabytes of free RAM in my system - there should be 
some defrag process running behind if there is such constrained kmalloc 
interface...

Zdenek

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