Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 16 3月, 2014 1 次提交
  3. 18 12月, 2013 2 次提交
  5. 31 10月, 2013 1 次提交
  7. 30 10月, 2013 1 次提交
  9. 18 10月, 2013 1 次提交
  11. 09 10月, 2013 2 次提交
  13. 01 10月, 2013 1 次提交
  15. 30 8月, 2013 1 次提交
    • D
      drm: implement experimental render nodes · 1793126f
      由 David Herrmann 提交于 
      Render nodes provide an API for userspace to use non-privileged GPU
commands without any running DRM-Master. It is useful for offscreen
rendering, GPGPU clients, and normal render clients which do not perform
modesetting.

Compared to legacy clients, render clients no longer need any
authentication to perform client ioctls. Instead, user-space controls
render/client access to GPUs via filesystem access-modes on the
render-node. Once a render-node was opened, a client has full access to
the client/render operations on the GPU. However, no modesetting or ioctls
that affect global state are allowed on render nodes.

To prevent privilege-escalation, drivers must explicitly state that they
support render nodes. They must mark their render-only ioctls as
DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must
support clients without any attached master.

If filesystem access-modes are not enough for fine-grained access control
to render nodes (very unlikely, considering the versaitlity of FS-ACLs),
you may still fall-back to fd-passing from server to client (which allows
arbitrary access-control). However, note that revoking access is
currently impossible and unlikely to get implemented.

Note: Render clients no longer have any associated DRM-Master as they are
supposed to be independent of any server state. DRM core highly depends on
file_priv->master to be non-NULL for modesetting/ctx/etc. commands.
Therefore, drivers must be very careful to not require DRM-Master if they
support DRIVER_RENDER.

So far render-nodes are protected by "drm_rnodes". As long as this
module-parameter is not set to 1, a driver will not create render nodes.
This allows us to experiment with the API a bit before we stabilize it.

v2: drop insecure GEM_FLINK to force use of dmabuf
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      1793126f
  17. 19 8月, 2013 6 次提交
  19. 07 8月, 2013 1 次提交
  21. 23 7月, 2013 3 次提交
  23. 28 6月, 2013 1 次提交
    • D
      drm: add hotspot support for cursors. · 4c813d4d
      由 Dave Airlie 提交于 
      So it looks like for virtual hw cursors on QXL we need to inform
the "hw" device what the cursor hotspot parameters are. This
makes sense if you think the host has to draw the cursor and interpret
clicks from it. However the current modesetting interface doesn't support
passing the hotspot information from userspace.

This implements a new cursor ioctl, that takes the hotspot info as well,
userspace can try calling the new interface and if it gets -ENOSYS it means
its on an older kernel and can just fallback.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      4c813d4d
  25. 10 5月, 2013 1 次提交
    • C
      drm: Use names of ioctls in debug traces · b9434d0f
      由 Chris Cummins 提交于 
      The intention here is to make the output of dmesg with full verbosity a
bit easier for a human to parse. This commit transforms:

[drm:drm_ioctl], pid=699, cmd=0x6458, nr=0x58, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc010645b, nr=0x5b, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc0106461, nr=0x61, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc01c64ae, nr=0xae, dev 0xe200, auth=1
[drm:drm_mode_addfb], [FB:32]
[drm:drm_ioctl], pid=699, cmd=0xc0106464, nr=0x64, dev 0xe200, auth=1
[drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a00000
[drm:drm_ioctl], pid=699, cmd=0x400c645f, nr=0x5f, dev 0xe200, auth=1
[drm:drm_ioctl], pid=699, cmd=0xc00464af, nr=0xaf, dev 0xe200, auth=1
[drm:intel_crtc_set_config], [CRTC:3] [NOFB]

into:

[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_THROTTLE
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_CREATE
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_TILING
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, IOCTL_MODE_ADDFB
[drm:drm_mode_addfb], [FB:32]
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_MMAP_GTT
[drm:drm_vm_open_locked], 0x7fd9302fe000,0x00a00000
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, I915_GEM_SET_DOMAIN
[drm:drm_ioctl], pid=699, dev=0xe200, auth=1, DRM_IOCTL_MODE_RMFB
[drm:intel_crtc_set_config], [CRTC:3] [NOFB]

v2: drm_ioctls is now a constant (Ville Syrjälä)
Signed-off-by: NChris Cummins <christopher.e.cummins@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      b9434d0f
  27. 30 4月, 2013 2 次提交
  29. 16 4月, 2013 1 次提交
  31. 28 2月, 2013 1 次提交
  33. 03 10月, 2012 1 次提交
  35. 02 10月, 2012 1 次提交
    • R
      drm: change ioctl permissions · 2216c9e7
      由 Rob Clark 提交于 
      Previously read-only KMS ioctls had some somewhat inconsistent settings
regarding whether mastership was required.  For example, GETRESOURCES
did not require master, but GETPLANERESOURCES, GETPROPERTY, etc. did.

At least for debugging, it is nice to be able to use modetest to dump
property values while another process is master, and there seems to
be no harm in allowing read-only access to the KMS state to other
processes.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      2216c9e7
  37. 13 9月, 2012 1 次提交
    • D
      drm: make buffer management work without DRM_MASTER · fb30edf5
      由 David Herrmann 提交于 
      DRM users should be able to create/destroy/manage dumb- and frame-buffers
without DRM_MASTER. These ioctls do not affect modesetting so there is no
reason to protect them by drm-master. Particularly, destroying buffers
should always be possible as a client has only access to buffers that they
created. Hence, there is no reason to prevent a client from destroying the
buffers, considering a simple close() would destroy them, anyway.

Furthermore, a display-server currently cannot shutdown correctly if it
does not have DRM_MASTER. If some other display-server becomes active (or
the kernel console), then the background display-server is unable to
destroy its buffers.
Under special curcumstances (like monitor reconfiguration) this might even
happen during runtime.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      fb30edf5
  39. 20 7月, 2012 1 次提交
  41. 21 6月, 2012 1 次提交
  43. 17 5月, 2012 1 次提交
  45. 30 3月, 2012 1 次提交
  47. 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
  49. 03 2月, 2012 1 次提交
    • M
      drm: remove master fd restriction on mode setting getters · a14b1b42
      由 Mandeep Singh Baines 提交于 
      Its useful to be able to call the mode setting getter ioctls.
Not requiring master fd, enables writing a simple program which
can query the state of the video system.

Since these ioctls are only "getters" there is no security or
synchronization issues which would require master fd. Opening
an new fd is already protected by the file permissions on the
device file.
Signed-off-by: NMandeep Singh Baines <msb@chromium.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Stephane Marchesin <marcheu@chromium.org>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>
      a14b1b42
  51. 05 1月, 2012 2 次提交
    • 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
    • I
      drm: no need to hold global mutex for static data · 53fead96
      由 Ilija Hadzic 提交于 
      drm_getcap and drm_version ioctls only reads static data,
there is no need to protect them with drm_global_mutex,
so make them DRM_UNLOCKED
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>
      53fead96
  53. 16 11月, 2011 2 次提交
  55. 11 11月, 2011 1 次提交
    • I
      drm: do not sleep on vblank while holding a mutex · 8f4ff2b0
      由 Ilija Hadzic 提交于 
      drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vblanks between the current and the
one it is waiting for. In some cases it can block the entire windowing
system.

v2: incorporate comments received from Daniel Vetter and
    Michel Daenzer.

v3/v4: after a lengty discussion with Daniel Vetter, it was concluded
       that the only thing not yet protected with locks and atomic
       ops is the write to dev->last_vblank_wait. It's only used in a
       debug file in proc, and the current code already employs no
       correct locking: the proc file only takes dev->struct_mutex,
       whereas drm_wait_vblank implicitly took the drm_global_mutex.
       Given all this, it's not worth bothering to try to fix
       the locks at this time.
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>
      8f4ff2b0