linux-kernel - Allocating huge physically continuous memory from kernel module

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]

Message-ID: <20091216225032.GA10005@merzeus.obrandt.org>
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)