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?
Since commit 9ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), the core provides the no-op functions when map and
map_atomic are not provided, so we no longer need assert that are
supplied by a dma-buf exporter.
Fixes: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers optional")
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Cc: Gerd Hoffmann <kraxel(a)redhat.com>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
---
drivers/dma-buf/dma-buf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 13884474d158..02f7f9a89979 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -405,7 +405,6 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
|| !exp_info->ops->map_dma_buf
|| !exp_info->ops->unmap_dma_buf
|| !exp_info->ops->release
- || !exp_info->ops->map
|| !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
--
2.18.0
Dear All,
The CMA related functions cma_alloc() and dma_alloc_from_contiguous()
have gfp mask parameter, but sadly they only support __GFP_NOWARN flag.
This gave their users a misleading feeling that any standard memory
allocation flags are supported, what resulted in the security issue when
caller have set __GFP_ZERO flag and expected the buffer to be cleared.
This patchset changes gfp_mask parameter to a simple boolean no_warn
argument, which covers all the underlaying code supports.
This patchset is a result of the following discussion:
https://patchwork.kernel.org/patch/10461919/
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Patch summary:
Marek Szyprowski (2):
mm/cma: remove unsupported gfp_mask parameter from cma_alloc()
dma: remove unsupported gfp_mask parameter from
dma_alloc_from_contiguous()
arch/arm/mm/dma-mapping.c | 5 +++--
arch/arm64/mm/dma-mapping.c | 4 ++--
arch/powerpc/kvm/book3s_hv_builtin.c | 2 +-
arch/xtensa/kernel/pci-dma.c | 2 +-
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/intel-iommu.c | 3 ++-
drivers/s390/char/vmcp.c | 2 +-
drivers/staging/android/ion/ion_cma_heap.c | 2 +-
include/linux/cma.h | 2 +-
include/linux/dma-contiguous.h | 4 ++--
kernel/dma/contiguous.c | 6 +++---
kernel/dma/direct.c | 3 ++-
mm/cma.c | 8 ++++----
mm/cma_debug.c | 2 +-
14 files changed, 25 insertions(+), 22 deletions(-)
--
2.17.1
On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote:
> On 07/04/2018 07:53 AM, Gerd Hoffmann wrote:
> > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote:
> > > On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote:
> > > > A driver to let userspace turn memfd regions into dma-bufs.
> > > >
> > > > Use case: Allows qemu create dmabufs for the vga framebuffer or
> > > > virtio-gpu ressources. Then they can be passed around to display
> > > > those guest things on the host. To spice client for classic full
> > > > framebuffer display, and hopefully some day to wayland server for
> > > > seamless guest window display.
> > > >
> > > > qemu test branch:
> > > > https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
> > > >
> > > > Cc: David Airlie <airlied(a)linux.ie>
> > > > Cc: Tomeu Vizoso <tomeu.vizoso(a)collabora.com>
> > > > Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
> > > > Cc: Daniel Vetter <daniel(a)ffwll.ch>
> > > > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
> > >
> > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be
> > > really cool. To give us some assurance that this is generically useful.
> >
> > Tomeu? Laurent?
>
> Sorry, but I think I will need some help to understand how this could help
> in the virtio-wl case [adding Zach Reizner to CC].
>
> Any graphics buffers that are allocated with memfd will be shared with the
> compositor via wl_shm, without need for dmabufs.
Within one machine, yes. Once virtualization is added to the mix things
become more complicated ...
When using virtio-gpu the guest will allocate graphics buffers from
normal (guest) ram, then register these buffers (which are allowed to be
scattered) with the host as resource.
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.
That dma-buf can be used by qemu internally (mmap it to get a linear
mapping of the resource, to avoid copying). It can be passed on to
spice-client, to display the guest framebuffer.
And I think it could also be quite useful to pass guest wayland windows
to the host compositor, without mapping host-allocated buffers into the
guest, so we don't have do deal with the "find some address space for
the mapping" issue in the first place. There are more things needed to
complete this of course, but it's a building block ...
cheers,
Gerd