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>] [day] [month] [year] [list]
Date:	Wed, 16 Dec 2009 23:50:32 +0100
From:	Torsten Landschoff <torsten@...ian.org>
To:	linux-kernel@...r.kernel.org
Cc:	torsten@...ian.org
Subject: Allocating huge physically continuous memory from kernel module

Hi kernel developers,

I need to allocate huge continuous DMA buffers for a PCI DMA device. I know
that the right way to do large DMA transfers is using scatter gather.

Anyway, given that I don't want to change too much and I wanted to get the
driver out of the kernel (so we can use the official distribution kernels),
I tried to make this possible from a module by just allocating blocks of
maximum buddy order and coalescing these into clusters. After all, most of the
time my systems /proc/buddyinfo tells me I have plenty of large blocks
available.

I am posting my code here in the hope that
a) it may be helpful to somebody fighting the same problem
b) you tell me why this is a bad thing to do
I know there are border cases with this approach sucking all usable memory,
but I think the memory should be freed again soon enough to keep the system
running. Please note that the module is only loaded at boot time.

As an aside, on my new development box, I can easily allocate 2 GB of
continuous memory with this hack.


Flame away ;-)

Friendly, Torsten

View attachment "bigalloc.c" of type "text/x-csrc" (7541 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ