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