kernel/include/drm/drm_vma_manager.h, branch linux-5.1.y

drm/i915: Prevent writing into a read-only object via a GGTT mmap

2018-07-13T15:14:04Z

If the user has created a read-only object, they should not be allowed to circumvent the write protection by using a GGTT mmapping. Deny it. Also most machines do not support read-only GGTT PTEs, so again we have to reject attempted writes. Fortunately, this is known a priori, so we can at least reject in the call to create the mmap (with a sanity check in the fault handler). v2: Check the vma->vm_flags during mmap() to allow readonly access. v3: Remove VM_MAYWRITE to curtail mprotect() Testcase: igt/gem_userptr_blits/readonly_mmap* Signed-off-by: Chris Wilson Cc: Jon Bloomfield Cc: Joonas Lahtinen Cc: Matthew Auld Cc: David Herrmann Reviewed-by: Matthew Auld #v1 Reviewed-by: Jon Bloomfield Reviewed-by: Joonas Lahtinen Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-4-chris@chris-wilson.co.uk

drm/vma-manager: drm_vma_node_start() constify argument

2017-11-11T10:19:37Z

Constify argument so functions calling into this take a const argument. Reviewed-by: Ville Syrjälä Signed-off-by: Noralf Trønnes Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20171107191348.17555-2-noralf@tronnes.org

drm: Extract drm_prime.h

2017-03-09T15:18:02Z

Plus a little bit more documentation. v2: Untangle the missing forward decls to make drm_prime|gem.h free-standing. Reviewed-by: Gustavo Padovan Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-3-daniel.vetter@ffwll.ch

drm: use drm_file to tag vm-bos

2016-09-19T09:22:08Z

Rather than using "struct file*", use "struct drm_file*" as tag VM tag for BOs. This will pave the way for "struct drm_file*" without any "struct file*" back-pointer. Signed-off-by: David Herrmann Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20160901124837.680-3-dh.herrmann@gmail.com

drm: Convert drm_vma_manager to embedded interval-tree in drm_mm

2016-08-08T08:05:17Z

Having added an interval-tree to struct drm_mm, we can replace the auxiliary rb-tree inside the drm_vma_manager with it. Signed-off-by: Chris Wilson Cc: David Herrmann Cc: dri-devel@lists.freedesktop.org Reviewed-by: David Herrmann Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1470236651-678-2-git-send-email-chris@chris-wilson.co.uk

drm/vma_manage: Drop has_offset

2016-04-20T10:58:53Z

It's racy, creating mmap offsets is a slowpath, so better to remove it to avoid drivers doing broken things. The only user is i915, and it's ok there because everything (well almost) is protected by dev->struct_mutex in i915-gem. While at it add a note in the create_mmap_offset kerneldoc that drivers must release it again. And then I also noticed that drm_gem_object_release entirely lacks kerneldoc. Cc: David Herrmann Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-14-git-send-email-daniel.vetter@ffwll.ch

drm/gem: Use kref_get_unless_zero for the weak mmap references

2015-10-19T09:00:44Z

Compared to wrapping the final kref_put with dev->struct_mutex this allows us to only acquire the offset manager look both in the final cleanup and in the lookup. Which has the upside that no locks leak out of the core abstractions. But it means that we need to hold a temporary reference to the object while checking mmap constraints, to make sure the object doesn't disappear. Extended the critical region would have worked too, but would result in more leaky locking. Also, this is the final bit which required dev->struct_mutex in gem core, now modern drivers can be completely struct_mutex free! This needs a new drm_vma_offset_exact_lookup_locked and makes both drm_vma_offset_exact_lookup and drm_vma_offset_lookup unused. v2: Don't leak object references in failure paths (David). v3: Add a comment from Chris explaining how the ordering works, with the slight adjustment that I dropped any mention of struct_mutex since with this patch it's now immaterial ot core gem. Cc: David Herrmann Reviewed-by: David Herrmann Reviewed-by: Chris Wilson Link: http://mid.gmane.org/1444901623-18918-1-git-send-email-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter

gpu/doc: Convert to markdown harder

2015-10-16T13:50:59Z

This snippet... * Lock VMA manager for extended lookups. Only *_locked() VMA function calls * are allowed while holding this lock. All other contexts are blocked from VMA * until the lock is released via drm_vma_offset_unlock_lookup(). ...causes markdown-enabled kernel-doc to barf: debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3247: parser error : Opening and ending tag mismatch: emphasis line 3247 and function *locked VMA function calls are allowed while ^ /root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml:3249: parser error : Opening and ending tag mismatch: function line 3249 and emphasis released via drmvma_offset_unlock_lookup. ^ unable to parse /root/airlied/debian/build/build-doc/Documentation/DocBook/gpu.aux.xml A quick workaround is to replace *_locked() by X_locked(). Cc: Danilo Cesar Lemes de Paula Signed-off-by: Lukas Wunner [danvet: Just drop the X_ too, the usual style is _unlocked, except that _ seems to be what annoys markdown.] Signed-off-by: Daniel Vetter

drm: init TTM dev_mapping in ttm_bo_device_init()

2014-03-16T11:23:42Z

With dev->anon_inode we have a global address_space ready for operation right from the beginning. Therefore, there is no need to do a delayed setup with TTM. Instead, set dev_mapping during initialization in ttm_bo_device_init() and remove any "if (dev_mapping)" conditions. Cc: Dave Airlie Cc: Ben Skeggs Cc: Maarten Lankhorst Cc: Alex Deucher Cc: Thomas Hellstrom Signed-off-by: David Herrmann

drm/vma: add access management helpers

2013-08-27T01:54:54Z

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: David Herrmann Signed-off-by: Dave Airlie