linux-kernel - Re: [RFC simple allocator v1 0/2] Simple 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: <20170123083545.6l2jxlkdtmebxy5b@phenom.ffwll.local>
Date:   Mon, 23 Jan 2017 09:35:45 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Benjamin Gaignard <benjamin.gaignard@...aro.org>
Cc:     linaro-kernel@...ts.linaro.org, arnd@...db.de, labbott@...hat.com,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, daniel.vetter@...ll.ch,
        laurent.pinchart@...asonboard.com, robdclark@...il.com,
        broonie@...nel.org, Sumit Semwal <sumit.semwal@...aro.org>
Subject: Re: [RFC simple allocator v1 0/2] Simple allocator

On Fri, Jan 20, 2017 at 04:32:29PM +0100, Benjamin Gaignard wrote:
> The goal of this RFC is to understand if a common ioctl for specific memory
> regions allocations is needed/welcome.
> 
> Obviously it will not replace allocation done in linux kernel frameworks like
> v4l2, drm/kms or others, but offer an alternative when you don't want/need to
> use them for buffer allocation.
> To keep a compatibility with what already exist allocated buffers are exported
> in userland as dmabuf file descriptor (like ION is doing).
> 
> "Unix Device Memory Allocator" project [1] wants to create a userland library
> which may allow to select, depending of the devices constraint, the best
> back-end for allocation. With this RFC I would to propose to have common ioctl
> for a maximum of allocators to avoid to duplicated back-ends for this library.
> 
> One of the issues that lead me to propose this RFC it is that since the beginning
> it is a problem to allocate contiguous memory (CMA) without using v4l2 or
> drm/kms so the first allocator available in this RFC use CMA memory.
> 
> An other question is: do we have others memory regions that could be interested
> by this new framework ? I have in mind that some title memory regions could use
> it or replace ION heaps (system, carveout, etc...).
> Maybe it only solve CMA allocation issue, in this case there is no need to create
> a new framework but only a dedicated ioctl.
> 
> Maybe the first thing to do is to change the name and the location of this 
> module, suggestions are welcome.
> 
> I have testing this code with the following program:

I'm still maintaining that we should just destage ION (with the todo items
fixed), since that is already an uabi to do this (afaiui at least), and
it's used on a few devices ... Please chat with Laura Abott.
-Daniel

> 
> #include <errno.h>
> #include <fcntl.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
> #include <sys/ioctl.h>
> #include <sys/mman.h>
> #include <sys/stat.h>
> #include <sys/types.h>
> 
> #include "simple-allocator.h"
> 
> #define LENGTH 1024*16
> 
> void main (void)
> {
> 	struct simple_allocate_data data;
> 	int fd = open("/dev/cma0", O_RDWR, 0);
> 	int ret;
> 	void *mem;
> 
> 	if (fd < 0) {
> 		printf("Can't open /dev/cma0\n");
> 		return;
> 	}
> 
> 	memset(&data, 0, sizeof(data));
> 
> 	data.length = LENGTH;
> 	data.flags = O_RDWR | O_CLOEXEC;
> 
> 	ret = ioctl(fd, SA_IOC_ALLOC, &data);
> 	if (ret) {
> 		printf("Buffer allocation failed\n");
> 		goto end;
> 	}
> 
> 	mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
> 	if (mem == MAP_FAILED) {
> 		printf("mmap failed\n");
> 	}
> 
> 	memset(mem, 0xFF, LENGTH);
> 	munmap(mem, LENGTH);
> 
> 	printf("test simple allocator CMA OK\n");
> end:
> 	close(fd);
> }
> 
> [1] https://github.com/cubanismo/allocator
> 
> Benjamin Gaignard (2):
>   Create Simple Allocator module
>   add CMA simple allocator module
> 
>  Documentation/simple-allocator.txt              |  81 ++++++++++
>  drivers/Kconfig                                 |   2 +
>  drivers/Makefile                                |   1 +
>  drivers/simpleallocator/Kconfig                 |  17 +++
>  drivers/simpleallocator/Makefile                |   2 +
>  drivers/simpleallocator/simple-allocator-cma.c  | 187 ++++++++++++++++++++++++
>  drivers/simpleallocator/simple-allocator-priv.h |  33 +++++
>  drivers/simpleallocator/simple-allocator.c      | 180 +++++++++++++++++++++++
>  include/uapi/linux/simple-allocator.h           |  35 +++++
>  9 files changed, 538 insertions(+)
>  create mode 100644 Documentation/simple-allocator.txt
>  create mode 100644 drivers/simpleallocator/Kconfig
>  create mode 100644 drivers/simpleallocator/Makefile
>  create mode 100644 drivers/simpleallocator/simple-allocator-cma.c
>  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
>  create mode 100644 drivers/simpleallocator/simple-allocator.c
>  create mode 100644 include/uapi/linux/simple-allocator.h
> 
> -- 
> 1.9.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch