Skip to content

L
linux
Switch branch/tag
  1. 29 Aug, 2013 27 commits
  3. 28 Aug, 2013 1 commit
  5. 27 Aug, 2013 3 commits
    • David Herrmann's avatar
      drm: verify vma access in TTM+GEM drivers · acb46527
      David Herrmann authored 
      GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().

TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instead of always returning
0.

All drivers assume that user-space can only get access to TTM buffers via
GEM handles. So whenever the verify_access() callback is called from
ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
TTM drivers (ie, vmwgfx).

v2: Switch to drm_vma_node_verify_access() to correctly return -EACCES if
    access was denied.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      acb46527
    • David Herrmann's avatar
      drm/gem: implement vma access management · ca481c9b
      David Herrmann authored 
      We implement automatic vma mmap() access management for all drivers using
gem_mmap. We use the vma manager to add each open-file that creates a
gem-handle to the vma-node of the underlying gem object. Once the handle
is destroyed, we drop the open-file again.

This allows us to use drm_vma_node_is_allowed() on _any_ gem object to see
whether an open-file is granted access. In drm_gem_mmap() we use this to
verify that unprivileged users cannot guess gem offsets and map arbitrary
buffers.

Note that this manages access for _all_ gem users (also TTM+GEM), but the
actual access checks are only done for drm_gem_mmap(). TTM drivers use the
TTM mmap helpers, which need to do that separately.
Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      ca481c9b
    • David Herrmann's avatar
      drm/vma: add access management helpers · 88d7ebe5
      David Herrmann authored 
      The VMA offset manager uses a device-global address-space. Hence, any
user can currently map any offset-node they want. They only need to guess
the right offset. If we wanted per open-file offset spaces, we'd either
need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
both doesn't really scale, we implement access management in the VMA
manager itself.

We use an rb-tree to store open-files for each VMA node. On each mmap
call, GEM, TTM or the drivers must check whether the current user is
allowed to map this file.

We add a separate lock for each node as there is no generic lock available
for the caller to protect the node easily.

As we currently don't know whether an object may be used for mmap(), we
have to do access management for all objects. If it turns out to slow down
handle creation/deletion significantly, we can optimize it in several
ways:
 - Most times only a single filp is added per bo so we could use a static
   "struct file *main_filp" which is checked/added/removed first before we
   fall back to the rbtree+drm_vma_offset_file.
   This could be even done lockless with rcu.
 - Let user-space pass a hint whether mmap() should be supported on the
   bo and avoid access-management if not.
 - .. there are probably more ideas once we have benchmarks ..

v2: add drm_vma_node_verify_access() helper
Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      88d7ebe5
  7. 24 Aug, 2013 5 commits
    • Rob Clark's avatar
      drm/msm: add basic hangcheck/recovery mechanism · bd6f82d8
      Rob Clark authored 
      A basic, no-frills recovery mechanism in case the gpu gets wedged.  We
could try to be a bit more fancy and restart the next submit after the
one that got wedged, but for now keep it simple.  This is enough to
recover things if, for example, the gpu hangs mid way through a piglit
run.
Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      bd6f82d8
    • Rob Clark's avatar
      drm/msm: add a3xx gpu support · 7198e6b0
      Rob Clark authored 
      Add initial support for a3xx 3d core.

So far, with hardware that I've seen to date, we can have:
 + zero, one, or two z180 2d cores
 + a3xx or a2xx 3d core, which share a common CP (the firmware
   for the CP seems to implement some different PM4 packet types
   but the basics of cmdstream submission are the same)

Which means that the eventual complete "class" hierarchy, once
support for all past and present hw is in place, becomes:
 + msm_gpu
   + adreno_gpu
     + a3xx_gpu
     + a2xx_gpu
   + z180_gpu

This commit splits out the parts that will eventually be common
between a2xx/a3xx into adreno_gpu, and the parts that are even
common to z180 into msm_gpu.

Note that there is no cmdstream validation required.  All memory access
from the GPU is via IOMMU/MMU.  So as long as you don't map silly things
to the GPU, there isn't much damage that the GPU can do.
Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      7198e6b0
    • Rob Clark's avatar
      drm/msm: add register definitions for gpu · 902e6eb8
      Rob Clark authored 
      Generated from rnndb files in:

https://github.com/freedreno/envytools

Keep this split out as a separate commit to make it easier to review the
actual driver.
Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      902e6eb8
    • Rob Clark's avatar
      drm/msm: basic KMS driver for snapdragon · c8afe684
      Rob Clark authored 
      The snapdragon chips have multiple different display controllers,
depending on which chip variant/version.  (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.)  And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.

To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.

The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently.  But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge.  This
would remove the 'msm_connector' base class.  But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..

This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.
Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      c8afe684
    • Rob Clark's avatar
      drm/msm: add register definitions · 0cf6c71d
      Rob Clark authored 
      Generated from rnndb files in:

https://github.com/freedreno/envytools

Keep this split out as a separate commit to make it easier to review the
actual driver.
Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      0cf6c71d
  9. 22 Aug, 2013 1 commit
    • Dave Airlie's avatar
      Merge branch 'gma500-next' of git://github.com/patjak/drm-gma500 into drm-next · 291d284c
      Dave Airlie authored 
      Here's some gma500 unifying and cleanups for drm-next. There is more stuff in
the pipe for 3.12 but I'd like to get these out of the way first.

* 'gma500-next' of git://github.com/patjak/drm-gma500: (35 commits)
  drm/gma500/cdv: Add and hook up chip op for disabling sr
  drm/gma500/cdv: Add and hook up chip op for watermarks
  drm/gma500: Rename psb_intel_encoder to gma_encoder
  drm/gma500: Rename psb_intel_connector to gma_connector
  drm/gma500: Rename psb_intel_crtc to gma_crtc
  drm/gma500/cdv: Convert to generic set_config()
  drm/gma500/psb: Convert to generic set_config()
  drm/gma500: Add generic set_config() function
  drm/gma500/cdv: Convert to generic save/restore
  drm/gma500/psb: Convert to generic save/restore
  drm/gma500: Add generic crtc save/restore funcs
  drm/gma500: Convert to generic encoder funcs
  drm/gma500: Add generic encoder functions
  drm/gma500/psb: Convert to generic cursor funcs
  drm/gma500/cdv: Convert to generic cursor funcs
  drm/gma500: Add generic cursor functions
  drm/gma500/psb: Convert to generic crtc->destroy
  drm/gma500/mdfld: Use identical generic crtc funcs
  drm/gma500/oak: Use identical generic crtc funcs
  drm/gma500/psb: Convert to gma_crtc_dpms()
  ...
      291d284c
  11. 21 Aug, 2013 3 commits
    • Daniel Vetter's avatar
      drm/prime: Always add exported buffers to the handle cache · d0b2c533
      Daniel Vetter authored 
      ... not only when the dma-buf is freshly created. In contrived
examples someone else could have exported/imported the dma-buf already
and handed us the gem object with a flink name. If such on object gets
reexported as a dma_buf we won't have it in the handle cache already,
which breaks the guarantee that for dma-buf imports we always hand
back an existing handle if there is one.

This is exercised by igt/prime_self_import/with_one_bo_two_files

Now if we extend the locked sections just a notch more we can also
plug th racy buf/handle cache setup in handle_to_fd:

If evil userspace races a concurrent gem close against a prime export
operation we can end up tearing down the gem handle before the dma buf
handle cache is set up. When handle_to_fd gets around to adding the
handle to the cache there will be no one left to clean it up,
effectily leaking the bo (and the dma-buf, since the handle cache
holds a ref on the dma-buf):

Thread A			Thread B

handle_to_fd:

lookup gem object from handle
creates new dma_buf

				gem_close on the same handle
				obj->dma_buf is set, but file priv buf
				handle cache has no entry

				obj->handle_count drops to 0

drm_prime_add_buf_handle sets up the handle cache

-> We have a dma-buf reference in the handle cache, but since the
handle_count of the gem object already dropped to 0 no on will clean
it up. When closing the drm device fd we'll hit the WARN_ON in
drm_prime_destroy_file_private.

The important change is to extend the critical section of the
filp->prime.lock to cover the gem handle lookup. This serializes with
a concurrent gem handle close.

This leak is exercised by igt/prime_self_import/export-vs-gem_close-race
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      d0b2c533
    • Daniel Vetter's avatar
      drm/prime: make drm_prime_lookup_buf_handle static · de9564d8
      Daniel Vetter authored 
      ... and move it to the top of the function to avoid a forward
declaration.
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      de9564d8
    • Daniel Vetter's avatar
      drm/prime: Simplify drm_gem_remove_prime_handles · 838cd445
      Daniel Vetter authored 
      with the reworking semantics and locking of the obj->dma_buf pointer
this pointer is always set as long as there's still a gem handle
around and a dma_buf associated with this gem object.

Also, the per file-priv lookup-cache for dma-buf importing is also
unified between foreign and native objects.

Hence we don't need to special case the clean any more and can simply
drop the clause which only runs for foreing objects, i.e. with
obj->import_attach set.

Note that with this change (actually with the previous one to always
set up obj->dma_buf even for foreign objects) it is no longer required
to set obj->import_attach when importing a foreing object. So update
comments accordingly, too.
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      838cd445
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7