linux-stable.git/drivers/gpu, branch v5.16.4

drm/vmwgfx: Fix stale file descriptors on failed usercopy

2022-01-29T09:59:24+00:00

commit a0f90c8815706981c483a652a6aefca51a5e191c upstream.

A failing usercopy of the fence_rep object will lead to a stale entry in
the file descriptor table as put_unused_fd() won't release it. This
enables userland to refer to a dangling 'file' object through that still
valid file descriptor, leading to all kinds of use-after-free
exploitation scenarios.

Fix this by deferring the call to fd_install() until after the usercopy
has succeeded.

Fixes: c906965dee22 ("drm/vmwgfx: Add export fence to file descriptor support")
Signed-off-by: Mathias Krause 
Signed-off-by: Zack Rusin 
Signed-off-by: Dave Airlie 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: reset dcn31 SMU mailbox on failures

2022-01-29T09:59:24+00:00

commit 83293f7f3d15fc56e86bd5067a2c88b6b233ac3a upstream.

Otherwise future commands may fail as well leading to downstream
problems that look like they stemmed from a timeout the first time
but really didn't.

Signed-off-by: Mario Limonciello 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Flush TLBs before releasing backing store

2022-01-29T09:59:23+00:00

commit 7938d61591d33394a21bdd7797a245b65428f44c upstream.

We need to flush TLBs before releasing backing store otherwise userspace
is able to encounter stale entries if a) it is not declaring access to
certain buffers and b) it races with the backing store release from a
such undeclared execution already executing on the GPU in parallel.

The approach taken is to mark any buffer objects which were ever bound
to the GPU and to trigger a serialized TLB flush when their backing
store is released.

Alternatively the flushing could be done on VMA unbind, at which point
we would be able to ascertain whether there is potential a parallel GPU
execution (which could race), but essentially it boils down to paying
the cost of TLB flushes potentially needlessly at VMA unbind time (when
the backing store is not known to be going away so not needed for
safety), versus potentially needlessly at backing store relase time
(since we at that point cannot tell whether there is anything executing
on the GPU which uses that object).

Thereforce simplicity of implementation has been chosen for now with
scope to benchmark and refine later as required.

Signed-off-by: Tvrtko Ursulin 
Reported-by: Sushma Venkatesh Reddy 
Reviewed-by: Daniel Vetter 
Acked-by: Dave Airlie 
Cc: Daniel Vetter 
Cc: Jon Bloomfield 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Remove unused compile options

2022-01-27T11:02:55+00:00

commit 50ca8cc7c0fdd9ab16b8b66ffb301fface101fac upstream.

Before the driver had screen targets support we had to disable explicit
bringup of its infrastructure because it was breaking screen objects
support.
Since the implementation of screen targets landed there hasn't been a
reason to explicitly disable it and the options were never used.
Remove of all that unused code.

Signed-off-by: Zack Rusin 
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Reviewed-by: Martin Krastev 
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-3-zack@kde.org
(cherry picked from commit 11343099d5ae6c7411da1425b6b162c89fb5bf10)
Signed-off-by: Thomas Zimmermann 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Remove explicit transparent hugepages support

2022-01-27T11:02:55+00:00

commit bc701a28c74e78d7b5aa2b8628cb3608d4785d14 upstream.

Old versions of the svga device used to export virtual vram, handling of
which was optimized on top of transparent hugepages support. Only very
old devices (OpenGL 2.1 support and earlier) used this code and at this
point performance differences are negligible.

Because the code requires very old hardware versions to run it has
been largely untested and unused for a long time.

Furthermore removal of the ttm hugepages support in:
commit 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
broke the coherency mode in vmwgfx when running with hugepages.

Fixes: 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
Signed-off-by: Zack Rusin 
Cc: Jason Gunthorpe 
Cc: Thomas Hellström 
Cc: Christian König 
Cc: Daniel Vetter 
Reviewed-by: Martin Krastev 
Reviewed-by: Maaz Mombasawala 
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-2-zack@kde.org
(cherry picked from commit 49d535d64d52945e2c874f380705675e20a02b6a)
Signed-off-by: Thomas Zimmermann 
Signed-off-by: Greg Kroah-Hartman

drm/vc4: crtc: Copy assigned channel to the CRTC

2022-01-27T11:02:54+00:00

commit eeb6ab4639590130d25670204ab7b6011333d685 upstream.

Accessing the crtc->state pointer from outside the modesetting context
is not allowed. We thus need to copy whatever we need from the KMS state
to our structure in order to access it.

In VC4, a number of users of that pointers have crept in over the years,
and the previous commits removed them all but the HVS channel a CRTC has
been assigned.

Let's move this channel in struct vc4_crtc at atomic_begin() time, drop
it from our private state structure, and remove our use of crtc->state
from our vblank handler entirely.

Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/
Link: https://lore.kernel.org/r/20211025141113.702757-4-maxime@cerno.tech
Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
Acked-by: Daniel Vetter 
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman

drm/vc4: Fix non-blocking commit getting stuck forever

2022-01-27T11:02:53+00:00

commit 0c250c150c74a90db298bf2a8bcd0a1dabed2e2f upstream.

In some situation, we can end up being stuck on a non-blocking that went
through properly.

The situation that seems to trigger it reliably is to first start a
non-blocking commit, and then right after, and before we had any vblank
interrupt), start a blocking commit.

This will lead to the first commit workqueue to be scheduled, setup the
display, while the second commit is waiting for the first one to be
completed.

The vblank interrupt will then be raised, vc4_crtc_handle_vblank() will
run and will compare the active dlist in the HVS channel to the one
associated with the crtc->state.

However, at that point, the second commit is waiting using
drm_atomic_helper_wait_for_dependencies that occurs after
drm_atomic_helper_swap_state has been called, so crtc->state points to
the second commit state. vc4_crtc_handle_vblank() will compare the two
dlist addresses and since they don't match will ignore the interrupt.

The vblank event will never be reported, and the first and second commit
will wait for the first commit completion until they timeout.

The underlying reason is that it was never safe to do so. Indeed,
accessing the ->state pointer access synchronization is based on
ownership guarantees that can only occur within the functions and hooks
defined as part of the KMS framework, and obviously the irq handler
isn't one of them. The rework to move to generic helpers only uncovered
the underlying issue.

However, since the code path between
drm_atomic_helper_wait_for_dependencies() and
drm_atomic_helper_wait_for_vblanks() is serialised and we can't get two
commits in that path at the same time, we can work around this issue by
setting a variable associated to struct drm_crtc to the dlist we expect,
and then using it from the vc4_crtc_handle_vblank() function.

Since that state is shared with the modesetting path, we also need to
introduce a spinlock to protect the code shared between the interrupt
handler and the modesetting path, protecting only our new variable for
now.

Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/
Link: https://lore.kernel.org/r/20211025141113.702757-3-maxime@cerno.tech
Fixes: 56d1fe0979dc ("drm/vc4: Make pageflip completion handling more robust.")
Acked-by: Daniel Vetter 
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman

drm/vc4: crtc: Drop feed_txp from state

2022-01-27T11:02:53+00:00

commit a16c66401fd831f70a02d33e9bcaac585637c29f upstream.

Accessing the crtc->state pointer from outside the modesetting context
is not allowed. We thus need to copy whatever we need from the KMS state
to our structure in order to access it.

In VC4, a number of users of that pointers have crept in over the years,
the first one being whether or not the downstream controller of the
pixelvalve is our writeback controller.

Fortunately for us, Since commit 39fcb2808376 ("drm/vc4: txp: Turn the
TXP into a CRTC of its own") this is no longer something that can change
from one commit to the other and is hardcoded.

Let's set this flag in struct vc4_crtc if we happen to be the TXP, and
drop the flag from our private state structure.

Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/
Link: https://lore.kernel.org/r/20211025141113.702757-2-maxime@cerno.tech
Fixes: 008095e065a8 ("drm/vc4: Add support for the transposer block")
Acked-by: Daniel Vetter 
Signed-off-by: Maxime Ripard 
Signed-off-by: Greg Kroah-Hartman

drm/vc4: hdmi: Make sure the device is powered with CEC

2022-01-27T11:02:50+00:00

commit 20b0dfa86bef0e80b41b0e5ac38b92f23b6f27f9 upstream.

Similarly to what we encountered with the detect hook with DRM, nothing
actually prevents any of the CEC callback from being run while the HDMI
output is disabled.

However, this is an issue since any register access to the controller
when it's powered down will result in a silent hang.

Let's make sure we run the runtime_pm hooks when the CEC adapter is
opened and closed by the userspace to avoid that issue.

Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support")
Reviewed-by: Dave Stevenson 
Signed-off-by: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20210819135931.895976-6-maxime@cerno.tech
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/display: Only set vblank_disable_immediate when PSR is not enabled

2022-01-27T11:02:50+00:00

commit 70897848730470cc477d5d89e6222c0f6a9ac173 upstream.

[Why]
PSR currently relies on the kernel's delayed vblank on/off mechanism
as an implicit bufferring mechanism to prevent excessive entry/exit.

Without this delay the user experience is impacted since it can take
a few frames to enter/exit.

[How]
Only allow vblank disable immediate for DC when psr is not supported.

Leave a TODO indicating that this support should be extended in the
future to delay independent of the vblank interrupt.

Fixes: 92020e81ddbeac ("drm/amdgpu/display: set vblank_disable_immediate for DC")

Acked-by: Alex Deucher 
Reviewed-by: Harry Wentland 
Signed-off-by: Nicholas Kazlauskas 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman