1. 21 8月, 2013 1 次提交
    • D
      drm/gem: fix up flink name create race · a8e11d1c
      Daniel Vetter 提交于
      This is the 2nd attempt, I've always been a bit dissatisified with the
      tricky nature of the first one:
      
      http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html
      
      The issue is that the flink ioctl can race with calling gem_close on
      the last gem handle. In that case we'll end up with a zero handle
      count, but an flink name (and it's corresponding reference). Which
      results in a neat space leak.
      
      In my first attempt I've solved this by rechecking the handle count.
      But fundamentally the issue is that ->handle_count isn't your usual
      refcount - it can be resurrected from 0 among other things.
      
      For those special beasts atomic_t often suggest way more ordering that
      it actually guarantees. To prevent being tricked by those hairy
      semantics take the easy way out and simply protect the handle with the
      existing dev->object_name_lock.
      
      With that change implemented it's dead easy to fix the flink vs. gem
      close reace: When we try to create the name we simply have to check
      whether there's still officially a gem handle around and if not refuse
      to create the flink name. Since the handle count decrement and flink
      name destruction is now also protected by that lock the reace is gone
      and we can't ever leak the flink reference again.
      
      Outside of the drm core only the exynos driver looks at the handle
      count, and tbh I have no idea why (it's just for debug dmesg output
      luckily).
      
      I've considered inlining the drm_gem_object_handle_free, but I plan to
      add more name-like things (like the exported dma_buf) to this scheme,
      so it's clearer to leave the handle freeing in its own function.
      
      This is exercised by the new gem_flink_race i-g-t testcase, which on
      my snb leaks gem objects at a rate of roughly 1k objects/s.
      
      v2: Fix up the error path handling in handle_create and make it more
      robust by simply calling object_handle_unreference.
      
      v3: Fix up the handle_unreference logic bug - atomic_dec_and_test
      retursn 1 for 0. Oops.
      
      v4: Squash in inlining of drm_gem_object_handle_reference as suggested
      by Dave Airlie and add a note that we now have a testcase.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      a8e11d1c
  2. 19 8月, 2013 5 次提交
  3. 07 8月, 2013 1 次提交
  4. 26 7月, 2013 1 次提交
  5. 25 7月, 2013 1 次提交
    • D
      drm/gem: convert to new unified vma manager · 0de23977
      David Herrmann 提交于
      Use the new vma manager instead of the old hashtable. Also convert all
      drivers to use the new convenience helpers. This drops all the
      (map_list.hash.key << PAGE_SHIFT) non-sense.
      
      Locking and access-management is exactly the same as before with an
      additional lock inside of the vma-manager, which strictly wouldn't be
      needed for gem.
      
      v2:
       - rebase on drm-next
       - init nodes via drm_vma_node_reset() in drm_gem.c
      v3:
       - fix tegra
      v4:
       - remove duplicate if (drm_vma_node_has_offset()) checks
       - inline now trivial drm_vma_node_offset_addr() calls
      v5:
       - skip node-reset on gem-init due to kzalloc()
       - do not allow mapping gem-objects with offsets (backwards compat)
       - remove unneccessary casts
      
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@gmail.com>
      0de23977
  6. 23 7月, 2013 1 次提交
  7. 02 7月, 2013 1 次提交
  8. 28 6月, 2013 2 次提交
  9. 08 6月, 2013 1 次提交
  10. 01 5月, 2013 1 次提交
    • D
      drm/prime: keep a reference from the handle to exported dma-buf (v6) · 219b4733
      Dave Airlie 提交于
      Currently we have a problem with this:
      1. i915: create gem object
      2. i915: export gem object to prime
      3. radeon: import gem object
      4. close prime fd
      5. radeon: unref object
      6. i915: unref object
      
      i915 has an imported object reference in its file priv, that isn't
      cleaned up properly until fd close. The reference gets added at step 2,
      but at step 6 we don't have enough info to clean it up.
      
      The solution is to take a reference on the dma-buf when we export it,
      and drop the reference when the gem handle goes away.
      
      So when we export a dma_buf from a gem object, we keep track of it
      with the handle, we take a reference to the dma_buf. When we close
      the handle (i.e. userspace is finished with the buffer), we drop
      the reference to the dma_buf, and it gets collected.
      
      This patch isn't meant to fix any other problem or bikesheds, and it doesn't
      fix any races with other scenarios.
      
      v1.1: move export symbol line back up.
      
      v2: okay I had to do a bit more, as the first patch showed a leak
      on one of my tests, that I found using the dma-buf debugfs support,
      the problem case is exporting a buffer twice with the same handle,
      we'd add another export handle for it unnecessarily, however
      we now fail if we try to export the same object with a different gem handle,
      however I'm not sure if that is a case I want to support, and I've
      gotten the code to WARN_ON if we hit something like that.
      
      v2.1: rebase this patch, write better commit msg.
      v3: cleanup error handling, track import vs export in linked list,
      these two patches were separate previously, but seem to work better
      like this.
      v4: danvet is correct, this code is no longer useful, since the buffer
      better exist, so remove it.
      v5: always take a reference to the dma buf object, import or export.
      (Imre Deak contributed this originally)
      v6: square the circle, remove import vs export tracking now
      that there is no difference
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      219b4733
  11. 28 2月, 2013 2 次提交
  12. 09 10月, 2012 1 次提交
    • K
      mm: kill vma flag VM_RESERVED and mm->reserved_vm counter · 314e51b9
      Konstantin Khlebnikov 提交于
      A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
      currently it lost original meaning but still has some effects:
      
       | effect                 | alternative flags
      -+------------------------+---------------------------------------------
      1| account as reserved_vm | VM_IO
      2| skip in core dump      | VM_IO, VM_DONTDUMP
      3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      
      This patch removes reserved_vm counter from mm_struct.  Seems like nobody
      cares about it, it does not exported into userspace directly, it only
      reduces total_vm showed in proc.
      
      Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.
      
      remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
      remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.
      
      [akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      314e51b9
  13. 03 10月, 2012 1 次提交
  14. 16 7月, 2012 1 次提交
    • C
      drm: Add colouring to the range allocator · 6b9d89b4
      Chris Wilson 提交于
      In order to support snoopable memory on non-LLC architectures (so that
      we can bind vgem objects into the i915 GATT for example), we have to
      avoid the prefetcher on the GPU from crossing memory domains and so
      prevent allocation of a snoopable PTE immediately following an uncached
      PTE. To do that, we need to extend the range allocator with support for
      tracking and segregating different node colours.
      
      This will be used by i915 to segregate memory domains within the GTT.
      
      v2: Now with more drm_mm helpers and less driver interference.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Dave Airlie <airlied@redhat.com
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@gmail.com>
      6b9d89b4
  15. 23 5月, 2012 1 次提交
  16. 22 5月, 2012 1 次提交
  17. 12 5月, 2012 1 次提交
    • R
      drm: pass dev to drm_vm_{open,close}_locked() · b06d66be
      Rob Clark 提交于
      Previously these functions would assume that vma->vm_file was the
      drm_file.  Although if in some cases if the drm driver needs to use
      something else for the backing file (such as the tmpfs filp) then this
      assumption is no longer true.  But vma->vm_private_data is still the
      GEM object.
      
      With this change, now the drm_device comes from the GEM object rather
      than the drm_file so the driver is more free to play with vma->vm_file.
      
      The scenario where this comes up is for mmap'ing of cached dmabuf's
      for non-coherent systems, where the driver needs to use fault handling
      and PTE shootdown to simulate coherency.  We can't use the vma->vm_file
      of the dmabuf, which is using anon_inode's address_space.  The most
      straightforward thing to do is to use the GEM object's obj->filp for
      vma->vm_file in all cases, for which we need this patch.
      Signed-off-by: NRob Clark <rob@ti.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      b06d66be
  18. 24 4月, 2012 1 次提交
  19. 30 3月, 2012 1 次提交
  20. 15 3月, 2012 1 次提交
    • D
      drm: add core support for unplugging a device (v2) · 2c07a21d
      Dave Airlie 提交于
      Two parts to this, one is simple unplug from sysfs for the device node.
      
      The second adds an unplugged state, if we have device opens, we
      just set the unplugged state and return, if we have no device
      opens we drop the drm device.
      
      If after a lastclose we discover we are unplugged we then
      drop the drm device.
      
      v2: use an atomic for unplugged and wrap it for users,
      add checks on open + mmap + ioctl entry points.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      2c07a21d
  21. 05 3月, 2012 1 次提交
  22. 30 1月, 2012 1 次提交
  23. 30 8月, 2011 1 次提交
  24. 25 7月, 2011 1 次提交
    • A
      drm/gem: add support for private objects · 62cb7011
      Alan Cox 提交于
      These small changes should allow GEM to be used with non shmem objects as
      well as shmem objects. In the GMA500 case it allows the base framebuffer to
      appear as a GEM object and thus acquire a handle and work with KMS.
      
      For i915 it ought to be trivial to get back the wasted memory but putting the
      system fb back into stolen RAM and in general I can imagine it allowing the
      use of GEM and thus KMS with all the older cards that have their framebuffer
      firmly placed in video RAM.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Tested-by: NRob Clark <rob@ti.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      62cb7011
  25. 28 6月, 2011 1 次提交
    • H
      drm/i915: use shmem_read_mapping_page · 5949eac4
      Hugh Dickins 提交于
      Soon tmpfs will stop supporting ->readpage and read_cache_page_gfp(): once
      "tmpfs: add shmem_read_mapping_page_gfp" has been applied, this patch can
      be applied to ease the transition.
      
      Make i915_gem_object_get_pages_gtt() use shmem_read_mapping_page_gfp() in
      the one place it's needed; elsewhere use shmem_read_mapping_page(), with
      the mapping's gfp_mask properly initialized.
      
      Forget about __GFP_COLD: since tmpfs initializes its pages with memset,
      asking for a cold page is counter-productive.
      
      Include linux/shmem_fs.h also in drm_gem.c: with shmem_file_setup() now
      declared there too, we shall remove the prototype from linux/mm.h later.
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Keith Packard <keithp@keithp.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5949eac4
  26. 21 6月, 2011 1 次提交
  27. 21 3月, 2011 1 次提交
    • C
      drm: Fix use-after-free in drm_gem_vm_close() · b74ad5ae
      Chris Wilson 提交于
      As we may release the last reference, we need to store the device in a
      local variable in order to unlock afterwards.
      
      [   60.140768] BUG: unable to handle kernel paging request at 6b6b6b9f
      [   60.140973] IP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111
      [   60.141014] *pdpt = 0000000024a54001 *pde = 0000000000000000
      [   60.141014] Oops: 0002 [#1] PREEMPT SMP
      [   60.141014] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/voltage_now
      [   60.141014] Modules linked in: uvcvideo ath9k pegasus ath9k_common ath9k_hw hid_egalax ath3k joydev asus_laptop sparse_keymap battery input_polldev
      [   60.141014]
      [   60.141014] Pid: 771, comm: meego-ux-daemon Not tainted 2.6.37.2-7.1 #1 EXOPC EXOPG06411/EXOPG06411
      [   60.141014] EIP: 0060:[<c1536d11>] EFLAGS: 00010046 CPU: 0
      [   60.141014] EIP is at __mutex_unlock_slowpath+0x5a/0x111
      [   60.141014] EAX: 00000100 EBX: 6b6b6b9b ECX: e9b4a1b0 EDX: e4a4e580
      [   60.141014] ESI: db162558 EDI: 00000246 EBP: e480be50 ESP: e480be44
      [   60.141014]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [   60.141014] Process meego-ux-daemon (pid: 771, ti=e480a000 task=e9b4a1b0 task.ti=e480a000)
      [   60.141014] Stack:
      [   60.141014]  e4a4e580 db162558 f5a2f838 e480be58 c1536dd0 e480be68 c125ab1b db162558
      [   60.141014]  db1624e0 e480be78 c10ba071 db162558 f760241c e480be94 c10bb0bc 000155fe
      [   60.141014]  f760241c f5a2f838 f5a2f8c8 00000000 e480bea4 c1037c24 00000000 f5a2f838
      [   60.141014] Call Trace:
      [   60.141014]  [<c1536dd0>] ? mutex_unlock+0x8/0xa
      [   60.141014]  [<c125ab1b>] ? drm_gem_vm_close+0x39/0x3d
      [   60.141014]  [<c10ba071>] ? remove_vma+0x2d/0x58
      [   60.141014]  [<c10bb0bc>] ? exit_mmap+0x126/0x13f
      [   60.141014]  [<c1037c24>] ? mmput+0x37/0x9a
      [   60.141014]  [<c10d450d>] ? exec_mmap+0x178/0x19c
      [   60.141014]  [<c1537f85>] ? _raw_spin_unlock+0x1d/0x36
      [   60.141014]  [<c10d4eb0>] ? flush_old_exec+0x42/0x75
      [   60.141014]  [<c1104442>] ? load_elf_binary+0x32a/0x922
      [   60.141014]  [<c10d3f76>] ? search_binary_handler+0x200/0x2ea
      [   60.141014]  [<c10d3ecf>] ? search_binary_handler+0x159/0x2ea
      [   60.141014]  [<c1104118>] ? load_elf_binary+0x0/0x922
      [   60.141014]  [<c10d56b2>] ? do_execve+0x1ff/0x2e6
      [   60.141014]  [<c100970e>] ? sys_execve+0x2d/0x55
      [   60.141014]  [<c1002a5a>] ? ptregs_execve+0x12/0x18
      [   60.141014]  [<c10029dc>] ? sysenter_do_call+0x12/0x3c
      [   60.141014]  [<c1530000>] ? init_centaur+0x9c/0x1ba
      [   60.141014] Code: c1 00 75 0f ba 38 01 00 00 b8 8c 3a 6c c1 e8 cc 2e b0 ff 9c 58 8d 74 26 00 89 c7 fa 90 8d 74 26 00 e8 d2 b4 b2 ff b8 00 01 00 00 <f0> 66 0f c1 43 04 38 e0 74 07 f3 90 8a 43 04 eb f5 83 3d 64 ef
      [   60.141014] EIP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111 SS:ESP 0068:e480be44
      [   60.141014] CR2: 000000006b6b6b9f
      Reported-by: NRusty Lynch <rusty.lynch@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      b74ad5ae
  28. 23 2月, 2011 1 次提交
    • C
      drm: Trim the GEM mmap offset hashtab · 4cb81ac2
      Chris Wilson 提交于
      Using an order 19 drm_ht for the mmap offsets is a little obscene. That
      means that will a fully populated GTT with every single object mmaped at
      least once in its lifetime, there will be exactly one object in each
      bucket.
      
      Typically systems only have at most a few thousand objects, though you
      may see a KDE desktop hit 50000. And most of those should never be
      mapped... On my systems, just using an order 10 ht would still have an
      average occupancy less than 1, so apply a small safety factor and
      use an order 12 ht, like the other mmap offset ht.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      4cb81ac2
  29. 07 2月, 2011 1 次提交
    • D
      drm: dumb scanout create/mmap for intel/radeon (v3) · ff72145b
      Dave Airlie 提交于
      This is just an idea that might or might not be a good idea,
      it basically adds two ioctls to create a dumb and map a dumb buffer
      suitable for scanout. The handle can be passed to the KMS ioctls to create
      a framebuffer.
      
      It looks to me like it would be useful in the following cases:
      a) in development drivers - we can always provide a shadowfb fallback.
      b) libkms users - we can clean up libkms a lot and avoid linking
      to libdrm_*.
      c) plymouth via libkms is a lot easier.
      
      Userspace bits would be just calls + mmaps. We could probably
      mark these handles somehow as not being suitable for acceleartion
      so as top stop people who are dumber than dumb.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      ff72145b
  30. 01 10月, 2010 3 次提交
  31. 28 9月, 2010 1 次提交
  32. 30 8月, 2010 1 次提交