unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Danny Milosavljevic <dannym@scratchpost.org>
To: Leo Famulari <leo@famulari.name>
Cc: 42686@debbugs.gnu.org
Subject: [bug#42686] Update to linux-libre 5.7
Date: Tue, 4 Aug 2020 12:36:57 +0200	[thread overview]
Message-ID: <20200804123657.67daa48e@scratchpost.org> (raw)
In-Reply-To: <20200802224356.GA4714@jasmine.lan>

[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]

Hi Leo,

On Sun, 2 Aug 2020 18:43:56 -0400
Leo Famulari <leo@famulari.name> wrote:

> * Enable the DMA-BUF userland memory heaps? This options creates per
> heap chardevs in /dev/dma_heap/ which allows userspace to allocate
> dma-bufs that can be shared between drivers. (DMABUF_HEAPS)
> 
> I don't really know what that means.

DMA ("direct memory access") is a method to automatically have devices transfer
memory blocks to (and/or from) volatile memory without the involvement of the
CPU.

dma-bufs are buffers that can be used for DMA.  These are distinct from regular
buffers because DMA is done without the involvement of the CPU, so setting up
a DMA buffer, telling the device the buffer location, and then freeing (or
swapping out) the buffer would be very bad (the device wouldn't know that it
is freed and would just continue using it, bypassing all the usual kernel
access checks--because it doesn't use the CPU in the first place).

A dma-buf heap is an allocator for dma-buf buffers and some limits where it
can allocate.  That is needed because peripheral chips have all kinds of
weird limitations on where the dma-buf buffer can be in memory (for example
some GPUs require the dma-buf buffers to be in the first 256 MiB of memory),
so the allocator has to take into account that the later devices can actually
reach the buffers and give them a dma-buf buffer at some weird location,
aliged like the device likes it and size-padded so the device doesn't
scribble over something else while using potentially huge block transfers.

A dma-buf userland memory heap is a device file in directory /dev/dma_heap/
which is connected to one specific dma-buf heap allocator in the kernel.
A userspace program can then use a weird ioctl to request a dma-buf buffer,
which then will be allocated.  A file descriptor will be returned to the
userspace program.  This FD can be inherited by child processes etc--the
usual.

These dma-buf buffers are annoying in that you can't swap them out, free them
and reallocate them later--or anything else you would do with normal memory.
Also, when using them you need to use a memory fence in order to synchronize
accesses between the CPU and the other devices that are using the buffer.

That means allocating those dma-buf buffers without needing them is a great
way to exhaust all RAM, with the kernel not having any recourse in reclaiming
them.  So, require root.

If the heap allocator that is used for that has a device-specific limit,
that is much safer, though.

The thing is mostly used by Android.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2020-08-04 10:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-02 22:43 [bug#42686] Update to linux-libre 5.7 Leo Famulari
2020-08-03  8:08 ` Mathieu Othacehe
2020-08-03 17:42   ` Leo Famulari
2020-08-03 21:00 ` Ricardo Wurmus
2020-08-03 21:55   ` Leo Famulari
2020-08-04 10:04     ` Ricardo Wurmus
2020-08-05 17:25       ` Leo Famulari
2020-08-04 10:36 ` Danny Milosavljevic [this message]
2020-08-05 17:24   ` Leo Famulari
2020-08-05 17:27 ` bug#42686: " Leo Famulari
2020-08-06  7:35   ` [bug#42686] " Mathieu Othacehe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200804123657.67daa48e@scratchpost.org \
    --to=dannym@scratchpost.org \
    --cc=42686@debbugs.gnu.org \
    --cc=leo@famulari.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).