user/sven/linux.git/include/drm/drm_file.h, branch v6.4.3

accel: Link to compute accelerator subsystem intro

2023-03-20T15:35:33Z

Commit 2c204f3d53218d ("accel: add dedicated minor for accelerator devices") adds link to accelerator nodes section of DRM internals doc (Documentation/gpu/drm-internals.rst), but the target doesn't exist. Instead, there is only an introduction doc for computer accelerator subsytem. Link to that doc until there is documentation of accelerator internals. Fixes: 2c204f3d53218d ("accel: add dedicated minor for accelerator devices") Signed-off-by: Bagas Sanjaya Reviewed-by: Jeffrey Hugo Signed-off-by: Oded Gabbay

accel: add dedicated minor for accelerator devices

2022-11-22T11:14:44Z

The accelerator devices are exposed to user-space using a dedicated major. In addition, they are represented in /dev with new, dedicated device char names: /dev/accel/accel*. This is done to make sure any user-space software that tries to open a graphic card won't open the accelerator device by mistake. The above implies that the minor numbering should be separated from the rest of the DRM devices. However, to avoid code duplication, we want the drm_minor structure to be able to represent the accelerator device. To achieve this, we add a new drm_minor* to drm_device that represents the accelerator device. This pointer is initialized for drivers that declare they handle compute accelerator, using a new driver feature flag called DRIVER_COMPUTE_ACCEL. It is important to note that this driver feature is mutually exclusive with DRIVER_RENDER. Devices that want to expose both graphics and compute device char files should be handled by two drivers that are connected using the auxiliary bus framework. In addition, we define a different IDR to handle the accelerators minors. This is done to make the minor's index be identical to the device index in /dev/. Any access to the IDR is done solely by functions in accel_drv.c, as the IDR is define as static. The DRM core functions call those functions in case they detect the minor's type is DRM_MINOR_ACCEL. We define a separate accel_open function (from drm_open) that the accel drivers should set as their open callback function. Both these functions eventually call the same drm_open_helper(), which had to be changed to be non-static so it can be called from accel_drv.c. accel_open() only partially duplicates drm_open as I removed some code from it that handles legacy devices. To help new drivers, I defined DEFINE_DRM_ACCEL_FOPS macro to easily set the required function operations pointers structure. Signed-off-by: Oded Gabbay Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jeffrey Hugo Reviewed-by: Dave Airlie Acked-by: Thomas Zimmermann Acked-by: Jacek Lawrynowicz Tested-by: Jacek Lawrynowicz Reviewed-by: Melissa Wen

drm: Remove the drm_get_unmapped_area() helper

2022-08-04T15:39:27Z

This has been only used by the vmwgfx driver and vmwgfx over the last year removed support for transparent hugepages on vram leaving drm_get_unmapped_area completely unused. There's no point in keeping unused code in core drm. Signed-off-by: Zack Rusin Reviewed-by: Thomas Hellström Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220425203152.1314211-2-zack@kde.org

drm: fix a kernel-doc typo

2022-04-04T16:00:19Z

Fix a build warning from 'make htmldocs' by correcting the lock name in the kernel-doc comment. include/drm/drm_file.h:369: warning: Function parameter or member 'master_lookup_lock' not described in 'drm_file' Signed-off-by: Randy Dunlap Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Reviewed-by: Simon Ser Signed-off-by: Simon Ser Link: https://patchwork.freedesktop.org/patch/msgid/20220403231040.18540-1-rdunlap@infradead.org

drm: add lockdep assert to drm_is_current_master_locked

2021-08-05T10:08:15Z

In drm_is_current_master_locked, accessing drm_file.master should be protected by either drm_file.master_lookup_lock or drm_device.master_mutex. This was previously awkward to assert with lockdep. Following patch ("locking/lockdep: Provide lockdep_assert{,_once}() helpers"), this assertion is now convenient. So we add in the assertion and explain this lock design in the kerneldoc. Signed-off-by: Desmond Cheong Zhi Xi Acked-by: Boqun Feng Acked-by: Waiman Long Acked-by: Peter Zijlstra (Intel) Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210802105957.77692-3-desmondcheongzx@gmail.com

drm: protect drm_master pointers in drm_lease.c

2021-07-20T18:22:19Z

drm_file->master pointers should be protected by drm_device.master_mutex or drm_file.master_lookup_lock when being dereferenced. However, in drm_lease.c, there are multiple instances where drm_file->master is accessed and dereferenced while neither lock is held. This makes drm_lease.c vulnerable to use-after-free bugs. We address this issue in 2 ways: 1. Add a new drm_file_get_master() function that calls drm_master_get on drm_file->master while holding on to drm_file.master_lookup_lock. Since drm_master_get increments the reference count of master, this prevents master from being freed until we unreference it with drm_master_put. 2. In each case where drm_file->master is directly accessed and eventually dereferenced in drm_lease.c, we wrap the access in a call to the new drm_file_get_master function, then unreference the master pointer once we are done using it. Reported-by: Daniel Vetter Signed-off-by: Desmond Cheong Zhi Xi Reviewed-by: Emil Velikov Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-6-desmondcheongzx@gmail.com

drm: serialize drm_file.master with a new spinlock

2021-07-20T18:17:58Z

Currently, drm_file.master pointers should be protected by drm_device.master_mutex when being dereferenced. This is because drm_file.master is not invariant for the lifetime of drm_file. If drm_file is not the creator of master, then drm_file.is_master is false, and a call to drm_setmaster_ioctl will invoke drm_new_set_master, which then allocates a new master for drm_file and puts the old master. Thus, without holding drm_device.master_mutex, the old value of drm_file.master could be freed while it is being used by another concurrent process. However, it is not always possible to lock drm_device.master_mutex to dereference drm_file.master. Through the fbdev emulation code, this might occur in a deep nest of other locks. But drm_device.master_mutex is also the outermost lock in the nesting hierarchy, so this leads to potential deadlocks. To address this, we introduce a new spin lock at the bottom of the lock hierarchy that only serializes drm_file.master. With this change, the value of drm_file.master changes only when both drm_device.master_mutex and drm_file.master_lookup_lock are held. Hence, any process holding either of those locks can ensure that the value of drm_file.master will not change concurrently. Since no lock depends on the new drm_file.master_lookup_lock, when drm_file.master is dereferenced, but drm_device.master_mutex cannot be held, we can safely protect the master pointer with drm_file.master_lookup_lock. Reported-by: Daniel Vetter Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-5-desmondcheongzx@gmail.com

drm/drm_vblank: set the dma-fence timestamp during send_vblank_event

2021-01-22T10:52:29Z

The explicit out-fences in crtc are signaled as part of vblank event, indicating all framebuffers present on the Atomic Commit request are scanned out on the screen. Though the fence signal and the vblank event notification happens at the same time, triggered by the same hardware vsync event, the timestamp set in both are different. With drivers supporting precise vblank timestamp the difference between the two timestamps would be even higher. This might have an impact on use-mode frameworks using these fence timestamps for purposes other than simple buffer usage. For instance, the Android framework [1] uses the retire-fences as an alternative to vblank when frame-updates are in progress. Set the fence timestamp during send vblank event using a new drm_send_event_timestamp_locked variant to avoid discrepancies. [1] https://android.googlesource.com/platform/frameworks/native/+/master/ services/surfaceflinger/Scheduler/Scheduler.cpp#397 Changes in v2: - Use drm_send_event_timestamp_locked to update fence timestamp - add more information to commit text Changes in v3: - use same backend helper function for variants of drm_send_event to avoid code duplications Changes in v4: - remove WARN_ON from drm_send_event_timestamp_locked Signed-off-by: Veera Sundaram Sankaran Reviewed-by: John Stultz Signed-off-by: Sumit Semwal [sumits: minor parenthesis alignment correction] Link: https://patchwork.freedesktop.org/patch/msgid/1610757107-11892-2-git-send-email-veeras@codeaurora.org

Merge drm/drm-next into drm-misc-next

2020-04-17T06:12:22Z

Backmerging required to pull topic/phy-compliance. Signed-off-by: Thomas Zimmermann

drm: rework SET_MASTER and DROP_MASTER perm handling

2020-03-30T11:20:32Z

This commit reworks the permission handling of the two ioctls. In particular it enforced the CAP_SYS_ADMIN check only, if: - we're issuing the ioctl from process other than the one which opened the node, and - we are, or were master in the past This ensures that we: - do not regress the systemd-logind style of DRM_MASTER arbitrator - allow applications which do not use systemd-logind to drop their master capabilities (and regain them at later point) ... w/o running as root. See the comment above drm_master_check_perm() for more details. v1: - Tweak wording, fixup all checks, add igt test v2: - Add a few more comments, grammar nitpicks. Cc: Adam Jackson Cc: Daniel Vetter Cc: Pekka Paalanen Testcase: igt/core_setmaster/master-drop-set-user Signed-off-by: Emil Velikov Reviewed-by: Adam Jackson Link: https://patchwork.freedesktop.org/patch/msgid/20200319172930.230583-1-emil.l.velikov@gmail.com