udmabuf builds without it, but if userspace can not create memfd
handles in the first place it is rather pointless to include it.
Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
---
drivers/dma-buf/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index 338129eb12..fc3fe3f04e 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -34,6 +34,7 @@ config UDMABUF
bool "userspace dmabuf misc driver"
default n
depends on DMA_SHARED_BUFFER
+ depends on MEMFD_CREATE
help
A driver to let userspace turn memfd regions into dma-bufs.
Qemu can use this to create host dmabufs for guest framebuffers.
--
2.9.3
On 09/07/2018 08:20 AM, jun qian wrote:
> The value in the wrong position will cause misunderstanding,
> when the debug infomations display in the window.
>
I think the existing order is okay, it's just not separated
well. It's "$count pages of order $order". I also just acked a
patch to remove all this code because it's dead on mainline
anyway. For future work, we should look to make the debugfs
output clearer to avoid ambiguity.
Thanks,
Laura
> Signed-off-by: jun qian <hangdianqj(a)163.com>
> ---
> drivers/staging/android/ion/ion_system_heap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
> index 701eb9f3b0f1..54b8a7710958 100644
> --- a/drivers/staging/android/ion/ion_system_heap.c
> +++ b/drivers/staging/android/ion/ion_system_heap.c
> @@ -225,10 +225,10 @@ static int ion_system_heap_debug_show(struct ion_heap *heap, struct seq_file *s,
> pool = sys_heap->pools[i];
>
> seq_printf(s, "%d order %u highmem pages %lu total\n",
> - pool->high_count, pool->order,
> + pool->order, pool->high_count,
> (PAGE_SIZE << pool->order) * pool->high_count);
> seq_printf(s, "%d order %u lowmem pages %lu total\n",
> - pool->low_count, pool->order,
> + pool->order, pool->low_count,
> (PAGE_SIZE << pool->order) * pool->low_count);
> }
>
>
On Tue, Sep 04, 2018 at 02:07:49PM -0500, Gustavo A. R. Silva wrote:
> There is a potential execution path in which pointer memfd is NULL when
> passed as argument to fput(), hence there is a NULL pointer dereference
> in fput().
>
> Fix this by null checking *memfd* before calling fput().
>
> Addresses-Coverity-ID: 1473174 ("Explicit null dereferenced")
> Fixes: fbb0de795078 ("Add udmabuf misc device")
> Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com>
Pushed to drm-misc-next.
thanks,
Gerd
Hi,
> > qemu can use memfd to allocate guest ram. Now, with the help of
> > udmabuf, qemu can create a *host* dma-buf for the *guest* graphics
> > buffer.
>
> Guess each physical address in the iovec in
> VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING can be passed as the offset in the
> udmabuf_create_item struct?
Exactly.
https://git.kraxel.org/cgit/qemu/commit/?h=sirius/udmabuf&id=515a5b9f1215ea…
> Are you thinking of anything else besides passing the winsrv protocol across
> the guest/host boundary? Just wondering if I'm missing something.
The patch above uses the dmabuf internally in qemu. It simply mmaps it,
so qemu has a linear representation of the resource and can use it as
pixman image backing storage without copying the pixel data.
So it is useful even without actually exporting the dmabuf to other
processes.
cheers,
Gerd
PS: Any chance you can review the v7 patch?