1. 04 8月, 2016 1 次提交
    • K
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski 提交于
      The dma-mapping core and the implementations do not change the DMA
      attributes passed by pointer.  Thus the pointer can point to const data.
      However the attributes do not have to be a bitfield.  Instead unsigned
      long will do fine:
      
      1. This is just simpler.  Both in terms of reading the code and setting
         attributes.  Instead of initializing local attributes on the stack
         and passing pointer to it to dma_set_attr(), just set the bits.
      
      2. It brings safeness and checking for const correctness because the
         attributes are passed by value.
      
      Semantic patches for this change (at least most of them):
      
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
      
          @@
          f(...,
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          {
          ...
          }
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      and
      
          // Options: --all-includes
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
          type t;
      
          @@
          t f(..., struct dma_attrs *attrs);
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: NRobin Murphy <robin.murphy@arm.com>
      Acked-by: NHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
      Acked-by: Mark Salter <msalter@redhat.com> [c6x]
      Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
      Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
      Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
      Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
      Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
      Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
      Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      00085f1e
  2. 10 6月, 2016 1 次提交
  3. 17 5月, 2016 1 次提交
  4. 21 1月, 2016 1 次提交
    • M
      drm/rockchip: fix wrong pitch/size using on gem · e3c4abdb
      Mark Yao 提交于
      args->pitch and args->size may not be set by userspace, sometimes
      userspace only malloc args and not memset args to zero, then
      args->pitch and args->size is random, it is very danger to use
      pitch/size on gem.
      
      pitch's type is u32, and min_pitch's type is int, example,
      pitch is 0xffffffff, then pitch < min_pitch return true, then gem will
      alloc very very big bufffer, it would eat all the memory and cause kernel
      crash.
      
      Stop using pitch/size from args, calc them from other args.
      Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
      e3c4abdb
  5. 02 12月, 2015 1 次提交
    • H
      drm/rockchip: unset pgoff when mmap'ing gems · a8594f20
      Heiko Stuebner 提交于
      Commit 371f0f08 ("ARM: 8426/1: dma-mapping: add missing range check
       in dma_mmap()") introduced offset-checking for mappings, which collides
      with the fake-offset the drm sets for gems.
      
      Other drm-drivers set this offset to 0 before doing the mapping, so
      this looks like the correct way to go for rockchip as well.
      
      Fixes: 371f0f08 ("ARM: 8426/1: dma-mapping: add missing range check in dma_mmap()")
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      a8594f20
  6. 16 10月, 2015 1 次提交
  7. 11 8月, 2015 1 次提交
    • D
      drm/rockchip: Don't grab dev->struct_mutex for in mmap offset ioctl · 648a4ce7
      Daniel Vetter 提交于
      Since David Herrmann's mmap vma manager rework we don't need to grab
      dev->struct_mutex any more to prevent races when looking up the mmap
      offset. Drop it and instead don't forget to use the unref_unlocked
      variant (since the drm core still cares).
      
      Aside: I stumbled over the mmap handler which directly does a
      dma_mmap_attrs. But totally fails to grab a reference on the
      underlying object and hence looks like it happily just leaks the ptes
      since there's no guarantee the mmap isn't still around when
      gem_free_object is called. Which the kerneldoc of dma_mmap_attrs
      explicitly forbids.
      
      v2: Fixup compile fail 0-day spotted.
      
      Cc: Mark Yao <mark.yao@rock-chips.com>
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      648a4ce7
  8. 13 7月, 2015 1 次提交
    • D
      drm/rockchip: use drm_gem_mmap helpers · 8915bf20
      Daniel Kurtz 提交于
      Rather than (incompletely [0]) re-implementing drm_gem_mmap() and
      drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap
      routines.
      
      Once the core functions return successfully, the rockchip mmap routines
      can still use dma_mmap_attrs() to simply mmap the entire buffer.
      
      [0] Previously, we were performing the mmap() without first taking a
      reference on the underlying gem buffer.  This could leak ptes if the gem
      object is destroyed while userspace is still holding the mapping.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      8915bf20
  9. 07 7月, 2015 1 次提交
    • D
      drm/rockchip: use drm_gem_mmap helpers · 41315b79
      Daniel Kurtz 提交于
      Rather than (incompletely [0]) re-implementing drm_gem_mmap() and
      drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap
      routines.
      
      Once the core functions return successfully, the rockchip mmap routines
      can still use dma_mmap_attrs() to simply mmap the entire buffer.
      
      [0] Previously, we were performing the mmap() without first taking a
      reference on the underlying gem buffer.  This could leak ptes if the gem
      object is destroyed while userspace is still holding the mapping.
      Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      41315b79
  10. 16 3月, 2015 1 次提交
  11. 09 1月, 2015 1 次提交
  12. 02 12月, 2014 1 次提交