1. 19 8月, 2013 1 次提交
    • D
      drm: mark context support as a legacy subsystem · 7c510133
      Daniel Vetter 提交于
      So after a lot of digging around in git histories it looks like this
      has only ever be used by dri1 render clients. Hence we can fully
      disable the entire thing for modesetting drivers and so greatly reduce
      the attack surface for potential exploits (or at least tools like
      trinity ...).
      
      Also add the drm_legacy prefix for functions which are called from
      common code. To further reduce the impact on common code also extract
      all the ctx release handling into a function (instead of only
      releasing individual handles) and make ctxbitmap_cleanup return void -
      it can never fail.
      Reviewed-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7c510133
  2. 23 7月, 2013 3 次提交
  3. 28 2月, 2013 2 次提交
  4. 03 10月, 2012 1 次提交
  5. 24 4月, 2012 1 次提交
  6. 05 1月, 2012 1 次提交
    • I
      drm: make DRM_UNLOCKED ioctls with their own mutex · 09b4ea47
      Ilija Hadzic 提交于
      drm_getclient, drm_getstats and drm_getmap (with a few minor
      adjustments) do not need global mutex, so fix that and
      make the said ioctls DRM_UNLOCKED. Details:
      
        drm_getclient: the only thing that should be protected here
        is dev->filelist and that is already protected everywhere with
        dev->struct_mutex.
      
        drm_getstats: there is no need for any mutex here because the
        loop runs through quasi-static (set at load time only)
        data, and the actual count access is done with atomic_read()
      
        drm_getmap already uses dev->struct_mutex to protect
        dev->maplist, which also used to protect the same structure
        everywhere else except at three places:
        * drm_getsarea, which doesn't grab *any* mutex before
          touching dev->maplist (so no drm_global_mutex doesn't help
          here either; different issue for a different patch).
          However, drivers seem to call it only at
          initialization time so it probably doesn't matter
        * drm_master_destroy, which is called from drm_master_put,
          which in turn is protected with dev->struct_mutex
          everywhere else in drm module, so we are good here too.
        * drm_getsareactx, which releases the dev->struct_mutex
          too early, but this patch includes the fix for that.
      
      v2: * incorporate comments received from Daniel Vetter
          * include the (long) explanation above to make it clear what
            we are doing (and why), also at Daniel Vetter's request
          * tighten up mutex grab/release locations to only
            encompass real critical sections, rather than some
            random code around them
      Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      09b4ea47
  7. 30 8月, 2010 1 次提交
  8. 19 6月, 2009 1 次提交
  9. 13 3月, 2009 1 次提交
    • B
      drm: Split drm_map and drm_local_map · f77d390c
      Benjamin Herrenschmidt 提交于
      Once upon a time, the DRM made the distinction between the drm_map
      data structure exchanged with user space and the drm_local_map used
      in the kernel.
      
      For some reasons, while the BSD port still has that "feature", the
      linux part abused drm_map for kernel internal usage as the local
      map only existed as a typedef of the struct drm_map.
      
      This patch fixes it by declaring struct drm_local_map separately
      (though its content is currently identical to the userspace variant),
      and changing the kernel code to only use that, except when it's a
      user<->kernel interface (ie. ioctl).
      
      This allows subsequent changes to the in-kernel format
      
      I've also replaced the use of drm_local_map_t with struct drm_local_map
      in a couple of places. Mostly by accident but they are the same (the
      former is a typedef of the later) and I have some remote plans and
      half finished patch to completely kill the drm_local_map_t typedef
      so I left those bits in.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      f77d390c
  10. 29 12月, 2008 1 次提交
    • D
      drm: move to kref per-master structures. · 7c1c2871
      Dave Airlie 提交于
      This is step one towards having multiple masters sharing a drm
      device in order to get fast-user-switching to work.
      
      It splits out the information associated with the drm master
      into a separate kref counted structure, and allocates this when
      a master opens the device node. It also allows the current master
      to abdicate (say while VT switched), and a new master to take over
      the hardware.
      
      It moves the Intel and radeon drivers to using the sarea from
      within the new master structures.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7c1c2871
  11. 14 7月, 2008 1 次提交
    • D
      drm: reorganise drm tree to be more future proof. · c0e09200
      Dave Airlie 提交于
      With the coming of kernel based modesetting and the memory manager stuff,
      the everything in one directory approach was getting very ugly and
      starting to be unmanageable.
      
      This restructures the drm along the lines of other kernel components.
      
      It creates a drivers/gpu/drm directory and moves the hw drivers into
      subdirectores. It moves the includes into an include/drm, and
      sets up the unifdef for the userspace headers we should be exporting.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      c0e09200
  12. 07 2月, 2008 1 次提交
  13. 15 10月, 2007 2 次提交
  14. 17 7月, 2007 1 次提交
  15. 11 7月, 2007 4 次提交
  16. 02 2月, 2006 1 次提交
  17. 02 1月, 2006 2 次提交
  18. 01 12月, 2005 1 次提交
  19. 30 9月, 2005 1 次提交
  20. 25 9月, 2005 1 次提交
    • D
      drm: lindent the drm directory. · b5e89ed5
      Dave Airlie 提交于
      I've been threatening this for a while, so no point hanging around.
      This lindents the DRM code which was always really bad in tabbing department.
      I've also fixed some misnamed files in comments and removed some trailing
      whitespace.
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      b5e89ed5
  21. 05 9月, 2005 1 次提交
  22. 05 8月, 2005 2 次提交
  23. 07 7月, 2005 1 次提交
  24. 23 6月, 2005 1 次提交
    • D
      drm: 32/64-bit DRM ioctl compatibility patch · 9a186645
      Dave Airlie 提交于
      The patch is against a 2.6.11 kernel tree.  I am running this with a
      32-bit X server (compiled up from X.org CVS as of a couple of weeks
      ago) and 32-bit DRI libraries and clients.  All the userland stuff is
      identical to what I am using under a 32-bit kernel on my G4 powerbook
      (which is a 32-bit machine of course).  I haven't tried compiling up a
      64-bit X server or clients yet.
      
      In the compatibility routines I have assumed that the kernel can
      safely access user addresses after set_fs(KERNEL_DS).  That is, where
      an ioctl argument structure contains pointers to other structures, and
      those other structures are already compatible between the 32-bit and
      64-bit ABIs (i.e. they only contain things like chars, shorts or
      ints), I just check the address with access_ok() and then pass it
      through to the 64-bit ioctl code.  I believe this approach may not
      work on sparc64, but it does work on ppc64 and x86_64 at least.
      
      One tricky area which may need to be revisited is the question of how
      to handle the handles which we pass back to userspace to identify
      mappings.  These handles are generated in the ADDMAP ioctl and then
      passed in as the offset value to mmap.  However, offset values for
      mmap seem to be generated in other ways as well, particularly for AGP
      mappings.
      
      The approach I have ended up with is to generate a fake 32-bit handle
      only for _DRM_SHM mappings.  The handles for other mappings (AGP, REG,
      FB) are physical addresses which are already limited to 32 bits, and
      generating fake handles for them created all sorts of problems in the
      mmap/nopage code.
      
      This patch has been updated to use the new compatibility ioctls.
      
      From: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      9a186645
  25. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4