linux-kernel - Buffer allocation question

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

Message-ID: <4C8E4898.7090407@collabora.co.uk>
Date:	Mon, 13 Sep 2010 16:51:52 +0100
From:	Ian Molton <ian.molton@...labora.co.uk>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Buffer allocation question

Hi,

I need to allocate some fairly large buffers which will be transferred 
via virtio to a hypervisor.

the pages dont have to be contiguous physically and aside from the first 
page int he transfer, the kernel wont really care about the contents of 
the buffer.

the pages do need to be mapped into userspace contiguously, however. 
They are also often dynamically resized.

the buffers can be quite large, and there can be several in flight at a 
given time. They must always be present in physical space (or virtio 
gets upset)

Obviously kmalloc() is out of the question, and given the size / 
quantity of the buffers, vmalloc() space is getting tight.

I'm struggling to find a good example of how this should be done.

the buffers will usually be filled all in one go, so it seems silly to 
fault them in a page at a time.

my first thought (before realising how limited vmalloc space is) was to 
vmalloc() them in my mmap() function, but this approach ran into trouble 
when I discovered that the mmap() call does not get called if the vma 
grows, so I cant then hook in and allocate more vmalloc() space.

It seems like it would be sensible to let userspace allocate the memory 
and then mmap() that range, but I've been told this is a bad idea.

Whats the best approach here? With the buffers being large I dont really 
want to transmit them in tiny bits either.

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